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Introduction 

This  document  is  a  description  of  the  final  Army  TYC-39 
Message  Switch  design  using  the  "Ada  Integrated  Methodology" 
developed  by  General  Dynamics  Data  Systems  Division. 

Although  the  rationale  for  the  design  decisions  is  presented 
here,  the  issues  that  were  debated  in  order  to  arrive  at  this 
design  are  discussed  in  the  project  "Final  Report".  The 
basis  for  this  design  is  contained  in  another  document,  "Ada 
Equivalent  System  Requirements  Specification",  which  explains 
the  functional  operation  of  a  message  switch  and  compatible 
interface  equipment.  All  three  of  the  documents  mentioned 
are  separately  submitted  as  a  part  of  this  project. 

The  design  description  is  organized  into  four  major  sections, 
which  are:  1)  System  Design,  2)  Detail  Design,  3)  Detail 
Hardware  Design  and  4)  Implementation.  This  project  was 
accomplished  without  any  preconceived  ideas  about 
hardware/software  partitioning.  Therefore,  the  entire  system 
design  was  completed  before  the  partitioning  was  done.  Then, 
because  of  the  limited  scope  of  the  project,  the  "message 
output"  section  was  chosen  for  detailed  design  and 
implementation . 

The  "System  Design"  section  contains  charts  and  diagrams  from 
which  the  structure  of  the  message  switch  was  derived.  The 
charts  begin  with  the  system  hierarchy,  which  shows  the  major 
packages  required  for  message  processing.  Run  switch  is 
presented  next  because  of  the  order  in  which  the  system  must 
be  started  and  initialized.  Once  up  and  running  with  a 
loaded  database,  the  message  processing  can  begin.  Most  of 
the  design  effort  was  concentrated  in  this  area  because  of 
the  critical  real  time  nature  of  this  process.  The  internal 
message  storage  structure  is  presented  in  the  message  schema 
and  the  detailed  logic  of  message  processing  is  shown  in  the 
functional  decomposition  diagrams.  The  data  structure 
diagrams  are  included  because  much  of  the  resulting  design  is 
based  on  the  ideas  derived  from  these  early  design  sessions 
(see  final  report). 

The  "Detail  Design"  section  provides  more  specific  details  of 
system  operation.  The  Ada  Unit  Specifications  were  developed 
for  the  structure  of  the  entire  switch  before  considering 
hardware/software  partitioning,  as  were  the  data  structures, 
traceability,  and  package  specification  dependency  chart. 

Then  the  analysis  that  was  given  to  system  partitioning  is 
presented . 

The  "Detail  Hardware  Design"  provides  some  information 
required  to  implement  the  system  as  partitioned  so  that  the 
messages  can  be  processed  within  the  constraints  of  the  non¬ 
functional  requirements.  Since  "message  output"  was  selected 
for  implementation,  only  the  input/output  section  of  the 
message  switch  hardware  detail  is  shown.  The  input 
processing  at  the  line  termination  unit  is  so  tightly  coupled 


to  message  output  that  both  processes  had  to  be  done 
together.  Because  a  multiprocessing  environment  was  chosen, 
the  detailed  hardware  section  describes  the  added 
complication  of  interprocessor  operations. 

Finally,  the  "Implementation"  section  describes  the  lowest 
level  block  diagram  of  the  Line  Termination  Unit  and  an 
explanation  of  the  intended  method  to  dynamically  allocate 
the  tasks  required  for  message  output.  Due  to  its  size,  the 
Ada  source  code  is  contained  in  another  volume  entitled, 
"Source  Code  Document". 


2.  Svstem  Design 


This  section  contains  system  charts  and  diagrams  representing 
design  decisions  based  on  the  "Ada  Equivalent  System 
Requirements  Specification  for  the  AN-TYC-39  Store  and 
Forward  Message  Switch".  The  design  proceeded  according  to  a 
methodology  tailored  for  this  project  and  described  in  the 
document  "Ada  Integrated  Methodology". 


System  Hierarch? 


The  chart  shown  in  Figure  2.1-1  shows  the  top  level  operation 
of  the  message  switch.  Run  Switch  and  Response  to  Operator 
are  functions  necessary  for  supervision  of  the  message 
processing.  They  are  described  in  the  Run  Switch  Section, 
but  not  to  the  detail  required  by  an  implementation.  The 
scope  of  the  project  was  somewhat  limited,  thus  this  aspect 
being  less  time  critical,  a  minimal  effort  was  applied  to 
this  task. 


The  other  parallelograms  presented  represent  Ada  tasks  with 
the  name  before  the  period  being  the  package  name  containing 
the  task.  The  name  after  the  period  is  the  task  name  if  the 
figure  is  a  parallelogram  or  a  procedure  name  if  the  figure 
is  a  rectangle.  The  internal  memory  structure  required  to 
store  the  large  volumes  of  data  handled  by  the  message  switch 
is  shown  by  the  Manage  Intransit  and  Manage  Overflow  diagram 
contained  in  section  2.4.5.  These  tasks  and  the  History  Ops 
package  are  utilized  as  necessary  out  of  the  other 
operational  tasks. 
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Figure  2.1-1  HIERARCHY  CHART 


2.2  Run  Switch 


2.2.1  Overview 


In  any  large  system  design  there  are  multitudes  of  details  which 
must  be  considered  and  coordinated  in  order  to  produce  the  most 
efficient  system.  Since  the  primary  purpose  of  this  contract  was 
to  develop  methods  of  using  Ada  and  to  investigate  its 
applicability  to  a  communication  system,  some  areas  of  the  system 
design  were  considered  in  less  detail  than  others.  These  areas 
were  chosen  for  two  reasons:  1)  they  were  standard  problems  which 
were  not  particularly  related  to  Ada  or  to  communications 
systems,  and  2)  to  reduce  the  complexity  of  the  job  and  allow 
indepth  design  and  analysis  of  unique  Ada  applications.  Although 
Run  Switch,  including  the  Operator  Interface,  was  selected  as  an 
area  less  deserving  of  detailed  examination,  in  the  interest  of 
thoroughness  and  integration  with  the  rest  of  the  system  design 
some  work  was  done  to  describe  the  basic  structure  and  define  th* 
required  operations.  The  following  Description  and  Theory  of 
Operation  is  an  overview  of  Run  Switch  and  is  not  intended  to  be 
a  full  treatment  of  the  problem. 


2.2.2  Operation 


Run  Switch  is  the  program  unit  which  initiates,  monitors  and 
terminates  switch  operation.  In  order  to  accomplish  these 
functions,  Run  Switch  contains  various  sub-program  units  in 
the  relationships  illustrated  in  sheets  1-4  of  the  Run  Switch 
diagram  and  described  below.  The  software  design  does  not 
make  use  of  Run  Switch  as  an  operating  system  or  an 
executive.  Ada  provides  the  operating  system  and  an 
executive  is  unnecessary.  Once  initiated,  the  switch 
software  will  be  either  self  driven  or  externally  driven 
rather  than  depending  on  an  executive.  Run  Switch  will 
simply  monitor  the  operation. 

A.  Initiation  -  Initiation  consists  of  the  capability  to 
begin  switch  operation  under  one  of  three  possible 
start-up  conditions:  1)  Cold  Start,  2)  Restart,  after 
an  ordered  (Normal)  shut-down,  or  3)  Recovery,  after  an 
emergency  or  unscheduled  shut-down.  Although  all  three 
operations  achieve  the  same  results  (an  operational 
switch  with  valid  tables  and  status  and  an  open  log), 
the  methods  by  which  these  results  are  achieved  are 
different  because  of  different  initial  conditions. 

1.  Start  Switch  -  This  is  the  "cold-start"  sequence 
and  assumes  a  lack  of  reliance  on  previous 
operating  information.  This  situation  might  be 
encountered  after  a  move  to  a  new  location  or  after 
switch  reconfiguration.  Provisions  are  made  for 
operator  entry  of  table  and  status  information  as 
well  as  use  of  prestored  information.  Since 
previous  messages  and  journal  information  are 
either  not  available  or  not  used,  these  items  are 
initially  set  to  the  null  state,  in  preparation  for 
actual  switch  operation. 

2.  Restart  Switch  -  This  sequence  assumes  resumption 
of  switch  operation  after  an  orderly  shut-down.  In 
this  case,  the  operating  tables,  status 
information,  and  the  final  balanced  journal  would 
have  been  saved  on  non-volatile  media.  Restart 
would  then  retrieve  this  information  and  request 
any  changes  from  the  operator.  The  final  journal 
would  be  the  basis  for  the  new  journal  and  saved 
messages  would  be  retrieved  from  the  long  history 
file  and  checked.  The  retrieved  messages  would  be 
written  into  Intransit  Storage. 

3.  Recover  Switch  -  This  sequence  is  slightly 
different  from  Restart  in  that  the  previous  shut- 
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down  was  either  unscheduled  or  an  emergency  and  the 
normal,  ordered  shut-down  process  was  not  followed. 
In  this  case,  all  of  the  required  information  may 
not  be  available  in  the  desired  format,  and  some 
preliminary  processing  may  be  required.  For 
example,  the  journal  will  be  available  from  non¬ 
volatile  media  but  in  an  emergency  shut-down  time 
may  not  have  been  available  to  balance  it. 

Therefore  the  balancing  must  be  done  to  maintain 
accountability,  before  normal  switch  operation 
resumes.  Tables  and  status  information  do  not 
present  the  same  problems  because  in  normal 
operation  this  information  is  periodically  saved, 
as  well  as  updated  when  changes  are  made.  Of 
course,  the  operator  will  be  able  to  change  the 
tables  or  status  as  conditions  warrant,  after  they 
are  reloaded. 

B.  Operation  -  During  normal  switch  operation,  Run  Switch 
will  be  concerned  with  monitoring  the  operation  of  the 
switch  and  maintaining  the  operator  interface.  This 
also  includes  monitoring  of  current  status  and  potential 
hardware  and  software  error  conditions,  as  well  as 
performing  background  diagnostics  and  periodically 
balancing  the  log. 

C.  Termination  -  Termination  of  switch  operation  can  take 
place  in  either  of  two  forms:  1)  Normal  (ordered)  Shut- 
Down  or  2)  Emergency  (unscheduled)  Shut-Down.  The 
normal  sequence  is  more  desirable,  however,  it  cannot  be 
assured  under  all  circumstances. 

1.  Stop  Switch  (Normal)  -  This  sequence  assumes  that 
sufficient  time  is  available  to  complete  an  orderly 
shut-down.  Since  this  time  is  a  minimum  only,  the 
DRY-UP  Command  is  a  sub-set  of,  or  a  preliminary  to 
a  Normal  Stop.  Depending  on  the  time  available, 
message  reception  and  transmission  could  be 
terminated  as  soon  as  the  current  message  on  a 
channel  is  finished  (Fast  Dry-Up),  or  reception 
could  be  terminated  with  receipt  of  the  current 
message  and  transmission  on  a  channel  terminated 
after  all  messages  available  for  that  channel  have 
been  transmitted.  In  any  case,  after  these 
conditions  are  met,  generation  and  saving  on  non¬ 
volatile  media  of  final  journal  and  other  operating 
information  would  be  accomplished.  At  this  point 
the  switch  is  no  longer  operational,  although  the 
operator  interface  portion  of  run  switch  will 
continue  to  run,  allowing  off  line  diagnostics, 
data  base  changes,  etc.  From  this  state,  power 
could  be  cut  off  with  no  detrimental  effects. 
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Stop  Switch  (Emergency)  -  This  sequence  causes 
immediate  termination  of  message  I/O,  and  if  time 
is  available,  updates  the  :g.  Since  the 
assumption  of  this  sequence  is  that  the  required 
time  for  a  normal  shut-down  is  not  available,  the 
sequence  attempts  to  accomplish  only  essential 
items.  It  is  anticipated  that  the  sequence  may  be 
entered  by  operator  command  or  upon  automatic 
detection  of  a  catastrophic  fault  (such  as  power 
failure) . 


2.2.3  Functions 
Reference  Figure  2.2-1 

A.  Load  Program  -  controls  the  loading  of  the  nonresident 
portions  of  the  switch  software  from  nonvolatile 
storage. 

B.  Get  RI  Table  -  determines  if  the  RI  Table  should  be 
retrieved  from  nonvolatile  storage  or  requested  from  the 
operator,  and  initiates  the  following  actions  as 
appropriate. 

1.  RI__OPS.INIT_RI_TABLE  -  prepares  the  RI  Table 
storage  space  for  the  entry  of  new  information. 

2.  RI_ OPS.LOAD_RI_TABLE  -  retrieves  the  prestored  or 
saved  RI  Table  data  from  nonvolatile  storage  and 
loads  that  information  into  the  RI  Table  storage 
space. 

3.  Prompt  Operator  for  Changes  -  initiates  an 
interactive  mode  for  operator  verification  of 
loaded  RI  Table  information  and  entry  or 
modification  of  information  as  required. 

4.  RI__OPS.SAVE__RI_TABLE  -  duplicates  the  Current  RI 
Table  in  nonvolatile  storage. 

C.  Get  Line  Table  -  determines  if  the  Line  Table  should  be 
retrieved  from  nonvolatile  storage  or  requested  from  the 
operator,  and  initiates  the  following  actions  as 
required . 

1.  LINE_TBL_OPS.INIT  -  prepares  the  Line  Table  storage 
space  for  the  entry  of  new  information. 

2.  LINE_TBL_OPS.LOAD  -  retrieves  the  prestored  or 
saved  Line  Table  data  from  nonvolatile  storage  and 
loads  that  information  into  the  Line  Table  storage 
space. 

3.  Prompt  Operator  for  Changes  -  initiates  an 
interactive  mode  for  operator  verification  of 
loaded  Line  Table  information  and  entry  or 
modification  of  information  as  required. 

4.  LINE_TBL_OPS.SAVE  -  duplicates  the  current  Line 
Table  in  nonvolatile  storage. 


Figure  2.2-1  (continued) 


D.  Get  Status  -  determines  if  the  Status  information  should 
be  retrieved  from  nonvolatile  storage  or  requested  from 
the  operator,  and-  initiates  the  following  actions  as 
required . 

1.  Initialize  Status  -  prepares  the  Status  storage 
space  for  the  entry  of  new  information. 

2.  Load  Status  -  retrieves  the  prestored  or  saved 
Status  from  nonvolatile  storage  and  loads  that 
information  into  the  Status  storage  space. 

3.  Prompt  Operator  for  Changes  -  initiates  an 
interactive  mode  for  operator  verification  of 
loaded  Status  information  and  entry  or  modification 
of  information  as  required. 

4.  Save  Status  -  duplicates  the  current  Status  in 
nonvolatile  storage. 

E.  AUDIT. AUDIT_INTRANSIT  -  used  during  recovery  to  read  the 
previous  log  and  generate  an  audit  which  will  become  the 
basis  for  the  new  Running  Audit.  Also  produces  a  list 
of  messages  to  be  recovered  from  Reference  Storage  and 
reintroduced. 

F.  HISTORY_OPS . REENTER_MESSAGES  -  accepts  a  list  of 
messages  to  be  recovered,  attempts  to  recover  those 
messages  and  reintroduce  them  into  the  system.  If 
necessary,  generates  a  list  of  messages  which  could  not 
be  recovered. 

G.  HISTORY_OPS. INIT_HISTORY  -  begins  a  new  History  with  no 
initial  entries.  Used  when  there  is  no  previous 
Journal . 

H.  Activate  Channels  -  controls  and  coordinates  the 
activation  of  the  individual  communication  channels. 

1.  Initializes  Channels  -  prepares  the  channels  for 
message  transmission  and  reception  by  specifying 
the  necessary  operating  controls  and  parameters  for 
each  individual  channel. 

2.  Generate  Service  Messages  -  as  appropriate,  Service 
Messages  will  be  generated  for  transmission  to  the 
channels'  distant  ends  to  indicate  that  a  link  has 
been  activated. 

3.  Generate  Control  Characters  -  as  appropriate, 
Control  Characters  will  be  generated  for 
transmission  to  the  Channel's  distant  ends  to 
indicate  that  a  link  has  been  activated. 
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4.  Save  Status  -  the  operational  status  and  operating 
parameters  of  all  channels  will  be  saved  in 
nonvolatile  storage. 


Figure  2.2-2 

I.  Monitor  Hardware  Errors  -  This  section  provides  for 
software  acceptance  of  monitoring  outputs.  It  also  will 
initiate  alarms,  corrective  action,  or  operator 
notification  as  appropriate.  Automatic  hardware  error 
checking  and  monitoring  is  assumed. 

J.  Monitor  Software  Errors  -  provide  for  the  detection, 
monitoring,  and  correction  of  software  errors  as  well  as 
tabulating  and  correcting  (when  possible)  exceptions 
raised  by  the  software,  perform  independent  error 
detection,  and  initiate  the  appropriate  action  for  the 
error  condition. 

K.  Monitor  Status  -  changes  in  equipment  status  will  be 
automatically  monitored.  This  may  cause  automatic 
switchovers  for  backed-up  equipment  as  well  as  alarms 
and  notices  to  the  operator.  Operator  entered  status 
changes  will  be  saved  for  future  reference. 

L.  Perform  Background  Diagnostics  -  this  task  will  be 
performed  continuously  during  switch  operation  to  test  . 
both  operational  capabilities  and  error  detection 
capabilities . 

1.  Save  -  Periodically  saves  in  nonvolatile  storage 
the  results  of  monitoring  hardware,  software  and 
status  and  of  Background  Diagnostics. 

2.  Print  -  initiates  the  hard  copy  output  of  detected 
error  conditions  and  the  periodic  printing  of  the 
status  of  the  monitored  conditions. 

M.  HISTORY_OPS.NEW_DAY  -  a  standard  package  that  closes  the 
old  day's  history  and  saves  the  current  audit,  begins  a 
new  day's  history,  then  audits  the  old  day's  history  and 
compares  the  generated  audit  to  the  saved  running  audit. 
Also  compiles  the  statistics  for  the  old  day,  initiates 
printing  the  statistics  and  clears  the  file  for  the  new 
day. 
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Figure  2.2-3 
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N.  Interface  to  Operator  -  provides  coordination  between 
the  various  subfunctions  of  the  operator  interface. 

These  subfunctions  interact  with  the  operator  as  well  as 
initiating  the  requested  operation(s) .  The  interactive 
portions  will  be  of  the  menu  driven,  selection  and 
response  type  with  automatic  verification  before 
activation . 

1.  Command  Interface  -  coordinates  the  activities 
required  for  command  acceptance  before  routing  the 
command  to  the  appropriate  subfunction  for 
execution . 

a.  Verify  Command  -  insures  that  an  operator 
entered  command  is  correct  and  valid  for  the 
context  in  which  it  is  being  saved. 

b.  Interpret  Command  -  converts  the  operator 
entered  command  from  a  series  of  key  strokes 
to  a  selection  code  with  appropriate 
parameters  for  routing  to  and  use  by  the  other 
subfunctions. 

2.  Control  RI  Table  -  depending  on  the  selection  code 
and  parameters  which  initiate  this  subfunction,  the 
appropriate  entry  point  to  the  RI_OPS  Package  is 
selected . 

a.  Read  -  provisions  to  allow  the  operator  to 
examine  or  verify  the  entries  in  the  RI  Table. 

b.  Modify  -  provisions  to  allow  the  changing, 
addition  or  deletion  of  any  or  all  of  the  RI 
Table  entries. 

c.  Save  -  initiates  the  storage  of  the  RI  Table 
in  nonvolatile  storage  for  future  reference. 

3.  Control  Line  Table  -  depending  on  the  selection 
code  and  parameters  which  initiate  this 
subfunction,  the  appropriate  entry  point  to  the 
LINE-OPS  Package  is  selected. 

a.  Read  -  provisions  to  allow  the  operator  to 
examine  or  verify  the  entries  in  the  Line 
Table. 

b.  Modify  -  provisions  to  allow  the  changing, 
addition  or  deletion  of  any  or  all  of  the  Line 
Table  entries. 

c.  Save  -  initiates  the  storage  of  the  Line  Table 
in  nonvolatile  storage  for  future  reference. 
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Trace  Message  -  provides  the  capability  to  search 
the  journal  and  retrieve  all  log  entries  pertaining 
to  a  particular  message  for  presentation  to  the 
operator. 

a.  Search  -  initiates  a  sequential  journal  search 
to  locate  the  next  log  entry  for  a  particular 
message . 

b.  Read  -  reads  the  next  log  entry  for 
presentation  to  the  operator. 

Control  Intransit  Thresholds  -  allows  the  operator 
to  check  or  change  the  threshold  levels  for 
Intransit  memory.  The  value  of  the  thresholds  (in 
percent)  determines  when  Overflow  Storage  will  be 
activated  and  deactivated. 

a.  Read  -  allows  the  operator  to  examine  the 
current  thresholds. 

b.  Set  -  allows  the  operator  to  set  or  modify  the 
current  thresholds. 

Access  Message  -  provides  facilities  for 
monitoring,  correcting,  originating  and  terminating 

messages. 

a.  Read  -  allows  the  operator  to  examine  a 
message  which  is  already  in  the  system. 

b.  Modify  -  allows  the  operator  to  change  or 
correct  a  message. 

c.  Generate  -  allows  the  operator  to  manually 
type  in  a  message  in  one  of  several  predefined 
formats. 

d.  Insert  -  places  or  replaces  a  message  in  the 
system. 

e.  Remove  -  takes  a  message  out  of  the  system. 

f.  Save  -  causes  a  message  to  be  saved  in 
volatile  storage. 

Print  -  is  an  output  driver  which  allows  certain 
types  of  information  and  operator  requested  items 
to  be  printed. 

Maintain  Switch  -  contains  the  off-line 
diagnostics,  and  fault  isolation  functions  as  well 
as  on-line  maintenance  functions  and  the 
Supervisor/Maintainer  functions. 


Figure  2.2-3  (continued) 

9.  Notify  Operator  -  an  output  interface  to  the 
operator  for  special  purpose,  time  critical  or 
warning  information. 

10.  Control  Status  -  provides  capabilities  for  the 

operator  to  examine  and  change  the  various  items  of 
status  and  condition  information. 

a.  Read  -  allows  the  operator  to  examine  the 
current  status. 

b.  Modify  -  allows  the  operator  to  change  certain 
status  items  to  reflect  the  current 
conditions. 

c.  Save  -  causes  all  of  the  current  status 
information  to  be  saved  in  nonvolatile 
storage. 

Figure  2.2-4 

O.  Stop  Receiving  Messages  -  the  first  step  in  any  ordered 
shut-down  or  "DRY-UP"  sequence.  In  general,  when 
activated  will  notify  each  receiving  function  to  cease 
accepting  new  messages.  Qualifiers  may  be  applied  to 
initiate  a  slower  or  a  line  specific  dry-up. 

P.  Finish  Transmitting  Messages  -  this  function  may  be 
initiated  to  cease  transmission  on  any  or  all  lines 
either  when  transmission  of  the  current  message  is 
complete  or  when  all  of  the  queued  messages  have  been 
transmitted . 

Q.  Deactivate  Channels  -  causes  the  transmission  of  control 
characters  or  service  messages,  as  appropriate,  to 
indicate  the  impending  channel  deactivation.  After  this 
transmission  channels  are  removed  from  active  service. 

R.  Save  All  Messages  Not  Transmitted  -  messages  or  message 
versions  which  have  not  been  transmitted  are  saved  in 
nonvolatile  storage,  for  later  recovery  and 
transmission . 

S.  HIST0RY_0PS.CL0SE_HIST0RY  -  A  standard  package  that 
closes  the  day's  history  and  saves  the  current  audit. 

The  day's  history  is  reaudited  and  the  generated  audit 
is  compared  to  the  saved  running  audit.  Statistics  are 
compiled  for  the  day. 

T.  Notify  Operator  -  at  the  various  stages  of  a  normal  stop 
the  operator  will  be  advised  of  the  current  progress  and 
status.  The  operator  will  also  be  advised  after  the 
initial  operations  of  an  emergency  stop  are  completed. 
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Figure  2.2-4  (continued) 


U.  Terminate  Input/Output  Processing  -  the  receipt  of 
incoming  messages  and  the  transmission  of  outgoing 
messages  will  be  terminated  immediately  when  an 
emergency  condition  is  detected. 

V.  Finish  Writing  Log  Entries  -  log  entries  which  are  in 
progress  or  pending  are  completed  so  that  the  most 
complete  journal  will  be  available  for  recovery.  This 
reduces  the  probability  of  transmission  of  duplicate 
messages. 

W.  Save  Running  Audit  -  the  current  running  audit  is  saved 
in  nonvolatile  storage  to  be  used  as  a  cross-check 
during  recovery. 


STOP 

SWITCH 

NORMAL 


Figure  2.2-4  Run  Switch 


2.3  Internal  Message  Structure 


The  message  schema  shown  in  Figure  2.3-1  was  chosen  to  take 
advantage  of  two  facets  of  the  messages  handled  by  the  switch. 

First,  the  messages  are  received  in  pieces.  Those  messages 
which  are  sent  in  synchronous  mode  are  received  in  blocks  of 
80  characters.  Asynchronous  messages  may  be  interrupted  by 
sequences  of  control  characters.  In  addition  to  these  problems, 
the  first  part  of  the  message  must  be  validated  during  the 
reception  of  the  remainder,  since  the  message  must  be  acknowledged 
very  shortly  after  the  end  of  message  is  received.  Therefore, 
the  message  is  stored  in  "chunks'*  of  80  characters,  which 
the  designers  chose  to  call  segments .  The  segments  are  placed 
in  a  doubly  linked  list,  using  next  segment  and  prior  segment 
pointers.  Since  the  segments  are  not  stored  together,  infor¬ 
mation  must  be  added  to  ensure  that  they  remain  properly  linked 
together.  The  only  item  that  is  required  by  the  performance 
specification  is  the  security  classification  of  the  message. 

For  further  checking  to  be  sure  that  no  segments  are  lost  or 
improperly  linked,  the  following  information  was  added:  the 
serial  number  of  the  nessage,  the  part  of  the  message  involved 
(MCB,  header,  body,  or  trailer),  and  a  number  which  starts 
with  one  for  each  part,  and  increases  by  one  for  each  segment. 

The  segments  are  also  time-stamped  for  logging  purposes. 

Most  messages  are  split  into  more  than  one  copy  during  processing. 
In  order  to  save  storage,  the  designers  decided  to  share  text 
between  versions  of  messages  at  the  part  level.  To  do  so,  a 
structure  called  the  part  header  was  created.  The  part  headers 
are  linked  to  the  first  and  last  segments  of  their  respective 
parts.  The  part  header  contains  the  name  of  the  part  involved, 
a  count  of  the  number  of  messages  which  are  using  this  part, 
and  a  count  of  the  segments  which  comprise  the  part.  This  last 
item  can  be  compared  with  the  segment  number  of  the  last 
segment  in  the  part. 

The  only  remaining  part  of  the  message  structure  is  the  version 
header.  Ths  information  contained  in  the  version  header  includes 
the  serial  number  of  the  message  plus  an  extension  to 
differentiate  between  version,  the  security  classification  of  the 
message,  the  precedence  of  the  message,  its  time  of  receipt, 
its  category  (normal  or  service)  the  output  line  to  which  the 
message  is  routed,  and  the  character  set  (ASCII  or  ITA)  of  the 
message.  The  version  headers  are  linked  to  the  part  headers 
through  an  array  of  access  variables  indexed  by  the  part  name. 


Figure  2.3-1  Mess.ige  Sclienin 


2.4  Functional  Decomposition  and  Interconnects  it 


2.4.1  Message  Input 

The  Message  Input  function  is  illustrated  in  Figures 
2.4-1  through  2.4-19.  The  dotted  parallelograms 
indicate  that  the  referenced  task  or  procedure  is 
elaborated  on  a  separate  page.  Other  symbology  and 
guidelines  to  interpreting  the  charts  is  discussed 
on  page  64  of  the  Ada  Integrated  Methodology. 
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Figure  2.4-3  Build  Valid  Asynchronous  Segment 


Figure  2.4-4  Build  Valid  Asynchronous  Segment  Interconnectivity 
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Figure  2.4-5  Build  Valid  Asynchronous  Segment  Interconnectivity 


Figure  2.4-6  Build  Valid  Asynchronous  Segment  Interconnectivity 
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Figure  2.4-11  Chart  for  Process  MCB 
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MSG  ID, SEC, CI1AK  COUNT, WHERE, STATE 

WHERE, STATE  Figure  2,4-15  Validate  HPJ  Message 
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Figure  2.4-16  Validate  HPA  Message 
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Figure  2.4-18  Chart  for  Validate  Message 
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Figure  2.4-19  Chart  for  Receive  Valid  Message 
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Figure  2.4-20  Manage  Message  Queues 


2.4.3  Message  Routini 


The  Message  Routing  function  is  illustrated  in 
Figures  2.4-24  through  2.4-31. 
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Figure  2.4-25  Process  Message  Interconnectivity 
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Figure  2.4-26  Route  Message 


Figure  2.4-27  Route  Message  Interconnect ivity 


Segregate  Routing  Line  Interconnectivity 


Figure  2.4-29  Complete  Version  Header  Interconnectivity 


TRANSLATE 

MESSAGE 


/*7* 

^  •  flf*,l  S,  H?2 


Mmnt^a.  ZV,  tymif  Aiw* 

Afcj»a^c  SO 
A*  ^c#**^*.  WuJuj 
TO 

ITrt  ^w^e,  Xj> 

^  sell  *4Mfl,  ID 
7~H  ^«s«4ffc  £D 

Ca»d  ^e«4«M{e  Xo 

M  >/lc«<a^6  XO,  *0bM«7«.  ZQ  pai^yvrm. 

t-,^4.  *■ 

t-nr 

f^ftsxaa*.  ZD,  pa*~hrvtnG, 

^tSW^C  XO,  Cfly^  ,  po  At  ^  1 3r\ 

rtc-.&.j*.  1.0,  ffr-hnim,  ^a/i1" 

Pjs'f  ’ 

£au*it ’,  p»«.4i«i\,  b+'f.'f'j 


Figure  2.4-31  Translate  Message ' Interconnectivity 
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2.4.4  Output  Message 


The  Output  Message  function  is  illustrated  in 
Figures  2.4-32  through  2.4-39. 
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Figure  2.4-32  Output  Message 
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Figure  2.4-33  Output  Message  Interconnectivity 
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Figure  2.4-36  Header  Valid 
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Figure  2.4-39  Decouple  Log  Interconnectivity 


.  5  Manage  Intransit,  Manage  Overflow 


The  Manage  Intransit,  Manage  Overflow  function  is 
illustrated  in  Figures  2.4-40  through  2.4-41. 
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Figure  2.4-40  MESSAGE  STORAGE  ALLOCATI ON/DEALLOCATI ON 


Figure  2.4-41  Manage  Intransit,  Manage  Overflow  Interconnectivity 
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Figure  2.5-1  Journal  Object 
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Figure  2.5-2  Reference  Storage  Object 


Figure  2.5-3  Physical  Port  Object 
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Figure  2.5-4  Message  Object 
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Figure  2.5-5  Logical  Port  Table  and 
Queue  Objects 


Figure  2.5-6  Route  Table  Object 
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High  Level  Port  Task 
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ASSEMBLE. MESSAGE  --  Construct  Next  Message 
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Figure  2.5-7  Example  of  Message  Input  Utilizing 
Object  Oriented  Structure 
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Process  Message 


loop  —  Loop  Forever 

READ.  INCOMINGS)  -  Get  Message 

LO0KJJP . ROUTE_TABLE  (MESSAGE)  -  Determine  Routing  List 

FOR  EACH  ROUTE_INDICATOR  —  FOR  EACH  DESTINATION 

CREATE. MESSAGE. VERS  I  ON  (LMF)  -  Create  Output  Format 
WRITE. OUTGOINGQ  (MESSAGE. VERSION)  —  Send  the  Message 
endfor 

endloop  —  End  Loop 


Figure  2.5-8  Example  of  Process  Message  Utilizing 
Object  Oriented  Structure 


Detailed  Design 


3.1  Ada  Unit  Specifications 


INPUT  PORT 


with  SEGMENT_OPS,  LINE_TBL_OPS ,  MESSAGE_OPS;  use  SEGMENT_OPS,  w - 

MESSAGE_OPS; 

package  INPUT_PORT  is 

task  type  R£CEIVE_VALID_MESSAGE  is 

entry  INITIATE (PHYSICAL_PORTtLINE_TBL_OPS.PHYSICAL_LINE) ;  r_, 

entry  TERM(PHYSICAL_PORTtLINE_TBL_OPS.PHYSICAL_1LINE)  ;  9 

end  RECEIVE 

type  SEG_STATUS  is  (GOOD, CAN ,CANTRAN, EXPIRED_PAUSE) ; 

type  RCV_STATUS  is  (VALID, HOLD, STORE_FAI LED, BAD_MCB,BAD_RIS, 

BAD  MODE,  BAD  SECURITY); 

-  - 

task  type  BUILD_MESSAGE_FROM_SEGMENTS  is 

entry  BUILD_SEG (NEW_S£GtSEG_PTR;SEG_RESULTtSEG_STATUS) ; 
entry  CHECK_MCB (MCB_SEG rout  SEG_PTR) ; 
entry  BUILD_MCB (HDR_SEG : out  SEG  PTR) ? 

entry  COMPLETE_MCB (MCB_SEG : SEG_PTR; TRL_SEG : out  SEG_PTR) ; 

entry  VALID_MCB(MCB_RESULT:RCV_STATUS) ;  *•“ 

entry  STORE_REF (STORE_SEG tout  SEG_PTR); 

entry  STORE_FAIL  (FAIL_SEG :  SEG__PTR)  ; 

entry  CHECK_SEG (VALID_SEG tout  SEG_PTR) ; 

entry  VALID_SEG (SEG_RESULTtRCV_STATUS) ; 

entry  POST_STATUS (MSG_STATUS tout  RCV  STATUS); 

entry  RECEIVE_MESSAGE  (MESSAGE  t  out  MSGID; MSG_STATUS  :  out  '■*  J 

RCV_STATUS);  1 

end  BUILD_MESSAGE_FROM_SEGMENTS; 

end  INPUT_PORT; 


■7  n  _ 
-  /  O 


SEGMENT  OPS 


with  GLOBAL_TYPES,MANAGE_STORAGE;  use  GLOBAL_TYPES ,MANAGE_STORAGE; 
package  SEGMENT_OPS  is 


—  NAME:  SEGMENT_OPS 

—  PURPOSE:  contains  the  data  definitions  and  operations  for  the 

—  manipulation  of  segments,  which  are  used  to  hold  the 

— ■  actual  text  of  messages. 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  17,  1982 


type  CHAR_COUNT  is  range  0..81; 
type  SEGMENT  is  private; 
type  SEG_PTR  is  access  SEGMENT; 
type  SEGMENT_NUMBER  is  range  0..550; 

procedure  RESET_SEG (SEG : SEG_PTR) ; 

—  SETS  TEXT  BUFFER  IN  SEGMENT  TO  EMPTY 

procedure  WRITE_SPECIFIC (SEG  :  SEG_PTR; 

WHERE  :  CHAR_COUNT; 

TEXT: STRING) ; 

—  PUTS  TEXT  INTO  SEGMENT  BUFFER  AT  SPECIFIC  LOCATION 
~T  USED  BY  REWRITE  IN  MESSAGE_OPS 

procedure  ADD_TEXT (SEG  :  SEG_PTR;  TEXT  :  STRING); 

—  PUTS  TEXT  INTO  SEGMENT  BUFFER 

function  READ_CHARS (SEG  :  SEG_PTR; 

WHERE, COUNT  :  CHAR_COUNT)  return  STRING; 

—  READS  COUNT  CHARACTERS  STARTING  AT  WHERE 

function  READ_CHARACTER_COUNT  (SEG  :  SEGJPTR)  return  CHAR_COUNT; 

—  RETURNS  THE  NUMBER  OF  CHARACTERS  IN  THE  BUFFER 

procedure  SET  TIME  (SEG  :  SEG_PTR;  HACK  :  DATE  TIME); 
function  READ_TIME (SEG  :  SEG_PTR)  return  DATE_TIME; 

—  SET  AND  READ  TIME  HACK  OF  SEGMENT 

procedure  SET  PART (SEG  :  SEG_PTR;  PART  :  PART_NAME); 
function  READ_PART (SEG  :  SEG_PTR)  return  PART_NAME; 

—  SET  AND  READ  THE  PART_NAME  FIELD  OF  THE  SEGMENT 

procedure  SET_EASN (SEG  :  SEG_PTR;  SERNO  :  EXT_SERIAL_NO) ; 
function  READ_EASN (SEG  :  SEG_PTR)  return  EXT_SERIAL_NO; 

—  SET  AND  READ  EXTENDED  SERIAL  NUMBER 

procedure  SET_SEGMENT_NUMBER (SEG  :  SEG_PTR; 

NUMBER  :  SEGMENT  NUMBER); 
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SEGMENT  OPS 


function  READ_SEGMENT_NUMBER (SEG  :  SEG_PTR)  return  SEGMENT_NUMBER ; 

—  SET  AND  READ  SEGMENT  SEQUENCE  FIELD 

procedure  SET_CLASS (SEG  s  SEG_PTR;  CLASS  :  SECURITY_CLASSIFICATION)  ; 
function  READ_C LASS (SEG  s  SEG_PTR)  return  SECURITY_CLASSIFICATION; 

—  SET  AND  READ  CLASSIFICATION 

procedure  LINK_SEGMENTS (SEG,  PRIOR_SEG  s  SEG_PTR) ; 

—  LINKS  SEG  INTO  A  SEGMENT  CHAIN 

—  SETS  FORWARD  POINTER  IN  PRIOR  SEGMENT  TO  SEG 

—  SETS  BACKWARD  POINTER  IN  SEG  TO  PRIOR_SEG 

—  SETS  FORWARD  POINTER  IN  SEG  TO  NULL 

function  NEXT_SEGMENT (SEG  :  SEG_PTR)  return  SEG_PTR; 
function  PRIOR_SEGMENT (SEG  :  SEG_PTR)  return  SEG_PTR; 

—  READ  NEXT  AND  PRIOR  SEGMENT  POINTERS 

procedure  FREE_SEGS (SEG  :  SEG_PTR)  ; 

—  FREES  AN  ENTIRE  CHAIN  OF  SEGMENTS 


function  GET  is  new  GET_INTRANSIT (SEGMENT, SEG_PTR) ; 
procedure  FREE  is  new  FREE_INTRANSIT (SEGMENT , SEG_PTR) ; 

—  GET  AND  FREE  INTRANSIT  STORAGE  FOR  SEGMENTS 

—  SEE  MANAGE_STORAGE  FOR  DETAILS 

private 


type  SEGMENT  is 
record 
BACK_SEG 
CLASS 
EASN 
FWDJ3EG 

NUMBER_CHARACTERS 

PART 

SEG_NO 

TEXT 

TIME 

end  record; 


SEG_PTR  :=null; 

SECURITY_CLASSIFICATION; 

EXT_SERIAL  NO; 

SEG_PTR  :*null; 

CHAR_COUNT  s*  0; 

PART_NAME; 

SEGMENT_NUMBER; 

STRING (I . .80} ; 

DATE  TIME; 


end  SEGMENT  OPS; 
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MANAGE  QUEUES 


with  MESSAGE_OPS; 
use  MESSAGE_OPS; 

package  MANAGE_QUEUES  is 


NAME:  MANAGE_QUEUES 

PURPOSE:  Task  that  manages  messages  after  reception  while  they 
awaiting  processing  for  routing. 


task  MANAGE_MESSAGE_QUEUES  is 

entry  QUEUE_NORMAL  (  MESSAGE:  MSGID  ); 
entry  QUEUE_SERVICE  (  MESSAGE:  MSGID  ); 
entry  QUEUE_REINTROD  (  MESSAGE:  MSGID  ); 
entry  DEQUEUE_OVERFLOW  (  MESSAGE:  out  MSGID  ); 

entry  RETRIEVE_FOR_PROCESS  (  PRECEDENCE  )  (  MESSAGE:  out  MSGID  ); 

end  MANAGE  MESSAGE  QUEUES; 


end  MANAGE  QUEUES; 


MAN AGE_TRANS LATED_QU E UE S 


with  MESSAGE_OPS ,  GLOBAL_TYPES ,  LINE_TBL_OPS ,  QUEUE; 
use  MESSAGE__OPS ,  GLOBAL_TYPES; 

package  MAN AG E_T R AN S LATE D_Q U E U E S  is 

—  NAME:  MANAGE_TRANSLATED_QUEUES 

—  PURPOSE:  Tasks  that  manage  messages  after  translation  while  they  ar 

awaiting  line  availabilty. 

task  type  MANAGE_OUTGOING  is 

entry  INIT  (  LOG_ID:  LOGICAL_LINE  ); 

entry  SET_PHYS_LINES  (  PHYS_LINES:  LINE_TBL_OPS . PHYSJPTR  ); 
entry  QUEUEJTRANSLATED  (  THIS_LINE:  LOGICAL_LINE;  MESSAGE:  MSGID  ); 
entry  QUEUE_REINTROD  (  THIS_LINE:  LOGICAL_LINE;  MESSAGE:  MSGID  ); 
entry  LINE_READY  (  THIS_LINE:  LINE_TBL_OPS . PHYSICAL_LINE  )? 
entry  KILL_NOW  (  THIS_LINE:  LINE  TBL_OPS . PHYSICAL_LINE  ); 
entry  KILL_LINE  (  THIS_LINE:  LINE_TBL_OPS . PHYSICAL_LINE  )? 
entry  K I LL_ON_EMPTY  (  THIS_LINE :  LINE_TBL_OPS . PHYSICAL_LINE  ); 
entry  INTERCEPT  (  THIS_LINE:  LOGICAL_LINE;  PREC:  PRECEDENCE; 

MEDIUM:  LINE_TBL_OPS .MEDIA  ); 

entry  REMOVE_INTERCEPT  (  THIS_LINE:  LOGICAL_LINE ;  PREC:  PRECEDENCE; 
MEDIUM:  LINE_TBL_OPS. MEDIA  ); 
end  MANAGE_OUTGOING; 

type  MANAGER  is  access  MANAGE_0UTG0ING; 

task  MANAGE_INTERCEPT  is 

entry  QUEUE_ONE  (  MESSAGE:  MSGID  ); 
entry  QUEUE_MANY  (  LIST:  QUEUE. HEAD  ); 
entry  DEQUEUE  (  MESSAGE:  MSGID  ); 
end  MAN AG E_I NTE RC E PT ; 

task  MOVE_INTERCEPT  is 

entry  START_INTERCEPT_OUT; 
entry  STOP_INTERCEPT_OUT; 
entry  START_REINTRO_OF_INTERCEPT ; 
entry  STOP_REINTRO_OF_INTERCEPT; 
end  MOVE_INTERCEPT; 

end  MANAGE_TRANSLATED_QUEUES; 


ml 
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MESSAGE  10 


with  GLOBAL_TYPES ,  MESSAGE_OPS,  SEGMENT_OPS;  use  GLOBAL_TYPES ,  '• 

MESSAGE_0PS ,  SEGMENT_OPS; 

package  MESSAGE_I0  is 


NAME:  MESSAGE_IO 

PURPOSE:  Input/output  subprograms  used  to  read/write  messages  to/from  -f" 

files  (  ie.,  OVERFLOW,  INTERCEPT) 


procedure  READ (FILE_NAME: STRING;  MESSAGE: out  MSGID) ; 
procedure  WRITE (FILE_NAME: STRING;  MESSAGE :MSGID) ; 
private 

type  KIND  is  (VERSION_HEADER,  PART  HEADER,  SEGMENT); 
type  BLOCK (PART_KIND: KIND  : ^SEGMENT)  is 
record 

case  PART_KIND  is 

when  VERSION_HEADER  «> 

VERSION : VERS ION_HEADER; 
when  PART_HEADER  *> 

PART_HEAD: PART_HEADER; 
when  SEGMENT  *> 

SEG: SEGMENT; 
end  case; 
end  record; 

package  BLOCK  10  is  new  INPUT_OUTPUT (BLOCK) ; 
type  IN_FILE  Ts  new  BLOCK_IO.IN  FILE; 
type  OUT_FILE  is  new  BLOCK_IO.OUT_FILE; 

end  MESSAGE  10; 
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QUEUE 


0 

with  GLOBAL_TYPES,MESSAGE_OPS;  use  GLOBAL_TYPES ,MESSAGE_OPS; 
package  QUEUE  is 


—  NAME:  QUEUE 

—  PURPOSE:  Encapsulates  the  queue  mechanisms  used  to  hold  the  messages 

—  during  waiting  stages  as  they  pass  thru  the  switch. 

—  PROGRAMMER:  SLN 

—  JATE :  18  MAY  82 


type  HEAD  is  private; 

■»  type  SET  is  array  (  MESSAGE  CAT,  PRECEDENCE  )  of  HEAD; 

procedure  ON_FRONT(  QUEUE:  Tn  out  HEAD;  MESSAGE:  in  MSGID  ); 

—  Place  a  message  properly  in  a  queue,  (  when  it  is  being 
—  reintroduced  as  from  overflow  or  intercept  ) . 

procedure  ON_BACK(  QUEUE:  in  out  HEAD;  MESSAGE:  in  MSGID  ); 

—  —  Place  a  message  properly  on  a  queue. 

procedure  FROM_FRONT (  QUEUE:  in  out  HEAD;  MESSAGE:  out  MSGID  ); 

—  Retreive  a  message  from  the  front  of  a  queue  for  normal 
processing. 

procedure  FROM_BACK (  QUEUE:  in  out  HEAD;  MESSAGE:  out  MSGID  ); 

. —  Retreive  a  message  from  the  back  of  a  queue  for  overflow, 
function  IS_NOT_EMPTY {  QUEUE:  in  HEAD  )  return  BOOLEAN; 

■  —  Test  the  empty  state  of  a  queue 

procedure  SPLIT (  MEDIUM:  in  MEDIA;  QUEUE:  in  out  HEAD; 

—  Segregate  messages  of  a  particular  media  from  a  queue  into  a 
seperate  list. 

LIST:  out  HEAD  ); 

B  procedure  MERGE (  MASTER:  in  out  HEAD;  SLAVE:  in  HEAD  ); 

—  Combine  two  queues  into  one. 

FOR_FROCESSING:  SET; 

F0R_3UTG0ING :  array  (  LOGICAL_LINES  )  of  SET; 

FOR_INTERCEPT:  SET; 

private 

r  type  ITEM; 

type  ITEM_PTR  is  access  ITEM; 
type  ITEM  is 
record 

NEXT, PRIOR:  ITEM_PTR; 

MESSAGE:  MSGID; 

TOR:  DATE_TIME; 
end  record; 
type  HEAD  is 
record 

FIRST, LAST:  ITEM_PTR  :=  null; 

COUNT:  INTEGER  :=0; 

■'  end  record; 

end  QUEUE; 
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PROCESS  MSG 


r 
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with  MESSAGE_OPS,RI_OPS,LINE_TBL_OPS;USe  MESSAGE_OPS ,RI_OPS, 
LINE_TBL_OPS; 

package  PROCESS_MSG  is 


—  NAME:  PROCESS_MSG 

—  PURPOSE:  contains  the  task  required  to  route  and  translate 

a  message.  (translations  required  depend  on  the 
type  of  exchange  required.) 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  17,  1982 


task  PROCESS_MESSAGE; 
end  PROCESS  MSG; 
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PHYSICAL  PORT 


—  JUNE  22  10:35  A.M.  —  PBD 

with  GLOBAL_TYPES ,  MESSAGE_OPSf  TIME_OPS,  HISTORY_OPS, 

LINE_TBL_OPS ,  RI_OPS,  HARDWARE_CLOCK ,  CONVERT_TO_ITA,  TASKS, 
SERVICE_MESSAGE_OPS; 

use  GLOBAL_TYPES,  MESSAGE_OPS,  TIME_OPS,  HISTORY_OPS, 

LINE_TBL_OPS,  RI_OPS,  HARDWARE_CLOCK ,  CONVERT_TO_ITA, 

SERVI VE_MESSAGE_OPS ; 

package  PHYSICAL_PORT  is 


—  NAME:  PHYSICAL_PORT 

—  PURPOSE:  contains  the  operations  and  data  definitions  dealing  with 

—  operations  of  the  physical  output  ports,  not  including 

—  operator  output. 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  17,  1982 


type  LOG_REQUEST  (LOG_TYP£  :  LOG_ENTRY)  is 
record 

BLOCKS  :  NUMJBLOCKS; 

LINE  :  PHYSICAL_LINE; 

MSG  :  MSGID; 

SEQ_NUM  :  CSN; 
case  LOG_TYPE  is 

when  CANCEL_OUT  I  CANTRAN  OUT  => 

CAN_R EASON  :  CANCEL_F EASON ; 
when  SCRUB  => 

SCR_REASON  :  SCRUB_K^ASON; 
when  REJECT  => 

REJ_REASON  :  REJECT_REASON; 
when  others  => 
null; 
end  case; 
end  record; 

type  MSG_STAT  is  (NORMAL_ACC,  COMPLETED_ACC ,  REJ); 
task  type  OUTPUT  MESSAGE  is 

entry  INIT  (LINE  :  PHYSICAL_LINE) ;  —  called  by  run  switch 
entry  SEND_MESSAGE (MSG  :  MSGID);  —  called  from  queue  task 
entry  PREEMPT  MESSAGE (NEW_MSG  :  MSGID; 

OLD_MSG  :  out  MSGID; 

STATUS  :  out  MSG_STAT) ;  —  called  from  queue 

entry  FIN I SHED_S ENDING;  ~  called  by  send 
entry  PREEMPT_CHECK (MSG  :  out  MSGID);  —  called  by  send 
entry  GET_MESSAGE (MSG  :  out  MSGID);  —  called  by  send 
end  OUTPUT  MESSAGE; 


PHYSICAL  PORT 
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task  type  SEND_MODE  II_IV  is 

entry  INIT  (LINE  :”PHYSICAL_LINE) ;  —  called  by  run  switch 
end  SEND_MODE_II_IV; 

task  type  SEND_MODE_V  is 

entry  INIT  (LINE  :  PHYSICAL_LINE) ;  —  called  by  run  switch 
end  SEND_MODE_V; 

task  type  SEND_MODE  I  is 

entry  INIT  (LINE  :  PHYSICAL_LINE) ;  —  called  by  run  switch 
end  SEND_MODE_I ; 

task  type  CONTROL_CHARACTER  is 

entry  INIT(P_LINE  :  PHYSICAL_LINE) ;  —  called  by  run  switch 
entry  PUT(CH  :  CHARACTER);  —  called  by  receiver 
entry  GET (CH  :  out  CHARACTER);  —  called  by  send 
end  CONTROL_CHARACTER; 

task  type  DECOUPLE  is 

entry  LOG (REQ  :  LOG_REQUEST) ;  —  called  by  send 

end  DECOUPLE; 

type  DECOUPLE_ACC  is  access  DECOUPLE; 
task  type  THROTTLE_INPUT  is 

entry  INIT (LINE  :  PHYSICALJLINE) ;  —  called  by  run  switch 

entry  START_THROTTLE; 
entry  STOP_THROTTLE; 
end  THROTTLE_INPUT; 

end  PHYSICAL  PORT; 
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MANAGE  INTRANSIT 


package  MANAGE_INTRANSIT  i3 


—  NAME:  MANAGE_INTRANSIT 

—  PURPOSE:  contains  procedures  and  tasks  to  manage  the  intransit 

—  storage  memory  resource. 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  17,  1982 


type  MEM_SIZE  is  INTEGER; 
type  THRESHOLD  is  range  0..100; 

procedure  SET__THRESHOLD  (LOWER: THRESHOLD  :-  60; 

UPPER : THRESHOLD  :■  70); 

—  SETS  LOWER  AND  UPPER  THRESHOLD  AS  SPECIFIED  IN  CALL 

—  MIDDLE  THRESHOLD  IS  SET  TO  THE  AVERAGE  OF  LOWER  AND  UPPER 

procedure  READJTHRESHOLD ( LOWER, MIDDLE, UPPER:  out  THRESHOLD); 

—  READS  CURRENT  THRESHOLD  SETTINGS 

task  CALCULATEJTHRESHOLD  is 

—  CALCULATES  THRESHOLD  VALUES  AND  INITIATES  OVERFLOW 

—  ACTIONS 

entry  GET (BITS :MEM_SIZE) ; 

~  USED  WHEN  GETTING  STORAGE 
entry  PUT (BITS :MEM_ISZE) ; 

—  USED  WHEN  RETURNING  STORAGE  TO  INTRANSIT 
end  CALCULATE  THRESHOLD; 


end  MANAGE  INTRANSIT 


MANAGE  OVERFLOW 


with  MESS AGE_OPS , MESS AGE_IO;  use  MESSAGE_OPS ,MESSAGE_IO; 
package  MANAGE_OVERFLOW  is 


—  NAME:  MANAGE_OVERFLOW 

—  PURPOSE:  contains  the  procedures  to  handle  the  overflow  of 

—  intransit  storage 

—  PROGRAMMER:  Paul  Dobbs 
~  DATE:  May  17,  1982 


task  OVERFLOW_DRIVER  is 
entry  START_OVERFLOW; 
entry  STOP__OVERFLOW; 
entry  START_REENTRY ; 
entry  STOP  REENTRY; 
end  OVERFLOWJDRIVER; 

end  MANAGE  OVERFLOW; 


-93- 


ASN 


package  ASN  is 


—  NAME:  ASN 

— 1  PURPOSE:  provides  the  definition  of  the  type  SER  NO_TYPE  and 

—  a  task  to  provide  sequential  serial  numbers. 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  14,  1982 


type  SER_NO__TYPE  is  private; 

task  MANAGE_ASN  is 

entry  SET (START :SER_NO  TYPE); 
entry  GET(NO:out  SER_NO_TYPE ) ; 
end  MANAGE_ASN; 

private 

type  SER__NO_TYPE  is  range  1.  .1_000_000; 
end  ASN;  ~ 
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AUDIT 


with  GLOBAL_TYP£S; use  GLOBAL_TYPES; 
package  AUDIT  is 


—  NAME:  AUDIT 

—  PURPOSE:  contains  data  definitions  and  operations  required  to 

~  audit  the  history  and  produce  lists  of  current  messages 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  17,  1982 


type  AUDI T_L I ST_N ODE ; 

type  AUDIT_LIST_PTR  is  access  AUD I T_LI ST_N ODE ; 
type  AUDIT_LIST_NODE  is 
record 

MESSAGE :EASN; 

NEXT: AUDIT_LIST_PTR; 
end  record; 
type  AUDIT_RECORD  is 
record 

NUM_INTRANS IT: INTEGER  :«  0; 

NUM_IN_OVERFLOW: INTEGER  :■  0; 

NUM_IN_INTERCEPT: INTEGER  :-  0; 

AUDIT_LI ST : AUDIT_LI ST_PTR ; 
end  record; 

CURRENT_AUDI T : AUDI T_RECORD ; 

—  RUNNING  AUDIT  FIGURES 

function  AUDIT_INTRANSIT  return  AUDIT_RECORD; 

—  READS  LOG  AND  PRODUCES  A  NEW  AUDIT  WITH  AT  LIST  OF 

—  INTRANSIT  MESSAGES 

type  OVERFLOW_RECORD  is  new  AUDIT  RECORD; 
function  AUDIT_OVERFLOW  return  OVERFLOW  RECORD; 

—  READS  LOG  &  PRODUCES  AN  AUDIT  WITH  A~LIST  OF  OVERFLOW  MESSAGES 

type  INTERCEPT_RECORD  is  new  AUDIT  RECORD; 
function  AUDIT_INTERCEPT  return  INTERCEPT  RECORD; 

—  READS  LOG  AND  PRODUCES  AN  AUDIT  WITH  A~LIST  OF  INTERCEPTED 

—  MESSAGES 

function  EQUAL (A, B:AUDIT_RECORD) return  BOOLEAN; 

—  COMPARES  TWO  AUDITS  FOR  SAME  NUMBERS  AND  SAME  MESSAGES  ON 

—  LISTS.  THE  ORDER  OF  LISTS  ARE  NOT  SIGNIFICANT. 

procedure  WRITE  AUDIT (OUTPUT_AUDIT: AUDIT_RECORD) ; 

—  WRITES  AUDIT~RECORD  ON  HISTORY  TAPES 


end  AUDIT 


BYTE  DEF 


package  BYTE  DEF  is 


—Name:  BYTE_DEF 

—Purpose:  to  define  bytes,  words,  and  long  words 

— Programmer :  Brian  G.  Sharpe 

—Date:  11  June  1982 

—Description: 

—  Bytes,  words,  and  long  words  are  defined  to  have  8,  16,  and  32 

—  bits,  respectively.  Also  defined  are  conversions  between  the 

—  different  types. 


BYTE  SIZE  :  constant  INTEGER  :*  8; 

MAX_lYTE_VALUE :  constant  INTEGER  :=  2  •«  BYTE  SIZE  -  1; 

subtype  BYTE  is  INTEGER  0. .MAX_BYTE_VALUE ; 

W0RD_SIZE  :  constant  INTEGER  :=  2  «  BYTE_SIZE; 

MAX  WORD_VALUE:  constant  INTEGER  :=  2  «»  WORD  SIZE  -  1; 

subtype  WORD  is  INTEGER  0. .MAX_WORD_VALUE ; 

L0NG_W0RD_SIZE  :  constant  INTEGER  :=  2  *  WORD  SIZE; 

MAX_L0NG  WORD  VALUE:  constant  INTEGER  :*  2  **  LONCl  W0RD_SIZE  -  1; 

subtype  UONG_WORD  is  INTEGER  Q. .MAX_LONG_WORD_VALUET 

—  representation  specifications  for  the  sizes  of  the  above  types 

for  BYTE 'SIZE  use  BYTE  SIZE; 

for  WORD 'SIZE  use  WORD  SIZE; 

for  LONG_WORD 'SIZE  use  LONG  WORD  SIZE; 


—merge  two  bytes  into  a  word 
function  BYTES_T0_W0RD( 

MST”SIG  BYTE, 

LST_SIG_BYTE  :  in  BYTE  )  return  WORD; 

— merge  two  words  into  a  long  word 
function  WORDS  T0_L0NG  W0RD( 

MST“SIG_W0RD, 

LST“SIG_WORD  :  in  WORD  )  return  L0NG_W0RD ; 

end  BYTE_DEF ; 


package  body  BYTE  DEF  is 


CONTROL 


package  CONTROL  is 


—  NAME:  CONTROL 

—  PURPOSE:  provides  a  task  type  for  controlling  access  to 

—  a  shared  resource. 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  5,  1982 


task  type  C0NTR0L_ACC£SS  is 
entry  START__READ; 
entry  FINISHED_READ; 
entry  START_WRITE ; 
entry  FINJSHED_WRITE; 
end  CONTROL_ACCESS; 

end  CONTROL; 
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HARDWARE  CLOCK 


Name:  HARDWARE_CLOCK 

Purpose:  to  implement  a  hardware,  binary  counter  clock 

Programmer:  Brian  G.  Sharpe 

Date:  8  June  1982 

Description : 

This  package  implements  a  hardware  clock  using  a  binary  counter. 

It  is  implemented  when  one  needs  a  time  DELTA  which  is  less  than 
DURATION 'DELTA. 

!!!!!!!!!!!  NOTE  !!!!!!!!!! 

This  is  useful  for  elapsed  time  only;  it  is  not  an  absolute 
(i.e.,  time  of  day)  clock. 

Since  the  elapsed  timer  is  implemented  in  hardware  with  binary  clock, 
it  will  "wrap  around"  from  "COUNTER__RANGE_MAX"  to  0. 

Thus,  the  user  must  ensure  that  the  largest  possible  elapsed  time  will 
.  be  less  than  the  time  to  pass  once  through  the  counter. 


—  package  declaration  section: 
type  HARDWARE_CLOCK_TIME  is  private; 

—  Subprogram  to  start  the  clock  chip  running  in  the  proper  configuration 
procedure  INIT_HARDWARE_CLOCK ; 

function  C0NVERT_T0_SEC0NDS  (  TIME_IN_HCT  :  HA.RDWARE_CLOCK_TIME  ) 

return  float; 

—  Determines  the  elapsed  time  between  inputs 

function  ELAPSED_TIME (  START_TIME,  FINAL_TIME  :  in  HARDWARE_CLOCK_TIME  ); 

—  Function  to  read  the  hardware  clock 

function  HARDWARE_CLOCK_READING  return  HARDWARE_CLOCK_TIME ; 
private  —  section 

CLOCK  SIZE  :  constant  :=  L0NG_W0RD_SIZE  ;  —  if  bits  in  counter  clock 

COUNTfR  RANGE_MAX  :  constant  :=  MAX-LONG  WORD_VALUE  ; 

CLOCK_ClTANNEL  LOW  WORD  is  constant  CHANNrLJ); 

CLOCK  CHANNEL~HIGff_WORD  is  constant  CHANNEL  1; 

USE_CHANNEL  :  SELECT_CHANNEL_ARRAY  :  =  (  true,  true,  false  ); 
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—  APRIL  07  1:24:00  —  PBD 

with  RI_0PS,  LINE_TBL_0PS,  TIME_0PS,  SEGMENT_OPS,  GLOBAL_TYPES ; 
use  RI_0PS,  LINEJTBL_0PS,  TIME_0PSf  SEGMENT_0PS,  GL0BAL_TYPES ; 

package  HISTORY  OPS  is 

type  ENTRY  TYFE  is  (LOG,  RI_SET,  SEGMENT); 
type  NUM_RlS  is  range  0..50; 

type  LOG  ENTRY  is  (SOM  IN,  EOM  IN,  REJECT,  CANCEL  IN, 

CANTl?AN_IN,  SOM  OUT,  EOM  OUT,  CANCEL  OUT,  CANTRAN  OUT, 

SCRUB,  0UT_T0_0?FL,  IN  FlOM  OVFL,  OUT  TO  INT,  IN  FROM  INT, 
SVC_GEN ,  VERSlON_OUT,  VERSION  IN); 
type  REJECT_REASON  is  (INVALID  HDF,  INVALID  RI,  INVALID_SECURITY , 
SECURITY_MISMATCH) ; 

type  CANCEL  REASON  is  (PREMPTED,  RE J_BY  RCVR); 
type  SCRUB_REASON  is  (OPERATOR); 
type  NUM_BLOCKS  is  range  0..50; 

type  RI_ARRAY  is  array  (INTEGER  range  <>)  of  RI_STRING; 
type  HISTORY_ENTRY  (ENT: ENTRY  TYPE : =SEGMENT ; 

RI_COUNT :  NUM_RIS :  =0 ;  LOG_fYPE:LOG_ENTRY:=SOM_IN)  is 
record 

case  ENT  is 
when  LOG  => 

CHANNEL: CHANNEL  DES; 

SEQ_NUM : CSN ; 

HACK : DATE_TIME ; 

MODE -.CHANNEL  MODE; 

BLOCK  COUNT :NUM  BLOCKS :*0; 

MCB: BOOLEAN :sFALSE; 

HEADER_SEGS : NUM  BLOCKS :=0; 

RIS: BOOLEAN :sFAlSE; 
case  LOG  TYPE  is 
when  RFJECT  > 

RE  REASON: REJECT  REASON; 
when  CANCEL  OUT  s> 

CAN  REASON: CANCEL  REASON; 
when  Scrub  s> 

SCR _REASON : SCRUB_REASON ; 
when  others  => 
null; 
end  case; 
when  RI  SET  => 

RIS: RT_ARRAY  (1..RI  COUNT); 
when  SEGMENT  s> 

SEG^BUF: SEGMENT; 
end  case; 
end  record; 

type  ENTRY_SET  is  array  (INTEGER  range  <>)  of  HISTORY_ENTRY ; 

type  HIST  STATUS  is  (OK,  END  OF  MEDIA,  ERROR); 

type  MESSAGE_LIST  is  array  (TNTFGER  range  <>)  of  EASN; 


task  ENTER  HIST  is 

entry  WRlTE(REC: ENTRY  SET;  STATUS:  out  HIST  STATUS); 
end  ENTER  HIST; 

—  USED  TS  WRITE  A  RECORD  OR  SET  OF  RECORDS  ON  THE  HISTORY 
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NAME:  GLOBAL_TYPES 

PURPOSE:  This  package  contains  the  types  global  to  the 

entire  software  project. 

PROGRAMMER:  Paul  Dobbs 
DATE:  May  17,  1982 


subtype 

type 

type 

type 


CHANNEL_DES 

CHANNEL_MODE 

CHAR_SET_TYPE 

CSN 


is  STRING  (1. .3) ; 
is  range  1..5; 
is  (  ANY,  ASC,  ITA  ); 
is  range  0..999; 


type  EXT_SERIAL_NO 
record 
ASN 

EXTENSION 
end  record; 

type  JULIAN_DATE 


is 


SER_NO_TYPE ; 

INTEGER  range  0..  100; 


type  DATE_TIME 
record 

DATE  :  JULIAN_DATE; 
TIME  :  DURATION; 
end  record; 


is  range  1..366; 
is 


type 

type 

type 


LOGICAL_LINE 

PART_NAME 

PRECEDENCE 


type 


is 

{  ROUTINE, 
PRIORITY, 
IMMEDIATE, 
FLASH, 

ECP, 

CRITIC  ) 

SECURITY_CLASSIFICATION 
is 

(  UNCLASS, 

EFTO, 

RESTRICTED, 

CONFIDENTIAL, 

SECRET, 

TOP_SECRET, 

SPECAT, 

DSSCS  )  ; 


is  range  0..50; 

is  (  MCB,  HEADER,  MSG_BODY,  TRAILER  ) 

R' 


I 


P' 

’O' 

•Z* 

•Y' 

’W' 


•  U* 

•e' 

•R* 

•C' 

•S' 

•  ip  t 

'A' 

'M' 
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y- 

u 


—  end  GLOBAL_TYPES; 

I 

(  ^ 

B 


E 
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—  NAME:  HISTORYJDPS 

—  PURPOSE:  contains  data  definitions  and  operations  pertaining  to 

—  the  history  files  (log  and  journal).'- 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  17,  1982 


1 


type  CANCEL_R EASON  is  (PREMPTED,  REJ  BY_RCVR) ; 
type  ENTRY_TYPE  is  (LOG,  RI_SET,  SEGMENT); 
type  HIST_STATUS  is  (OK,  END  OF  MEDIA,  ERROR); 

type  LOG_ENTRY  is  (SOM_IN,  EOM_IN,  REJECT,  CANCEL_IN,  CANTRAN_I N , 

SOM_OUT,  EOM_OUT,  CANCEL  OUT,  CANTRAN_OUT , 
SCRUB,  OUT_TO_OVFL,  IN_FROM_OVFL,  OUT  TO_INT, 
IN_FROM_INT,  SVC_GEN,  VERSION_OUT,  VERSION_IN) ; 
type  MESSAGE_LIST  is  array  (INTEGER  range  <>)  of  EXT_SERIAL_NO; 
type  NUM_B LOCKS  is  range  0..50; 
type  REJECT_REASON  is  (INVALID_HDR,  INVALID_RI, 

INVALID_SECURITY,  SECURITY_MISMATCH)  ; 
type  RI_ARRAY  is  array  (NUM_RIS  range  <>)  of  RI_STRING; 

■type  SCRUB_REASON  is  (OPERATOR); 


type  HISTORY_ENTRY  (ENT  :  ENTRY_TYPE  :*  SEGMENT; 

RI_COUNT  :  NUM_RIS  :*  0; 

LOG_TYPE  :  LOG_ENTRY  i-  SOM_IN)  is 

record 

case  ENT  is 


when  LOG  => 
BLOCK_COUNT 
CHANNEL 
HACK 

HEADER  SEGS 


MCB  : 

MODE  : 
RIS  : 
SEQ_NUM  : 
SER_NO  : 
case  LOG  TYPE 


NUM_B LOCKS; 
CHANNELJDES; 
DATE_TIME; 
NUM  BLOCKS; 


BOOLEAN; 

CHANNEL_MODE; 

BOOLEAN; 

CSN; 

EXT  SERIAL_NO; 
i  s 


Blocks  transmitted  or  received 
Channel  designator 
Time  of  event 

Number  of  header  segments  which 
are  present  in  the  log  entry 
May  be  zero 

Whether  an  MCB  segment 
is  present 
Mode  of  the  channel 
Whether  an  Rl_set  is  included 
CSN  for  asynch  only 
■  Message  extended  serial  number 
Reasons,  where  applicable 


when  REJECT  => 

REJ_REASON  :  REJECT_REASON; 
when  CANCEL_OUT  I  ,CANTRAN_OUT  => 
CAN  REASON  :  CANCEL  REASON; 


when  SCRUB  •*> 


r 
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SCR_REASON  :  SCRUB_REASON; 
when  others  ■>  ... 

null; 
end  case; 
when  RI  SET  => 

RI_S :RI_ARRAY  (1 . .RI_COUNT) ; 
when  SEGMENT  «> 

SEG_BUF  :  SEGMENTJDPS . SEGMENT; 
end  case; 
end  record; 

type  ENTRY_SET  is  array  (INTEGER  range  <>)  of  HI STORY_ENTRY ; 

—  An  ENTRY_SET  consists  of  a  HI STORY_ENTRY  of  type  LOG  followed  by 

—  An  optional  RI_SET  “ 

—  An  optional  MCB  SEGMENT 
—  0  or  more  header  SEGMENTS 

—  This  ordering  MUST  NOT  be  violated 

task  ENTER_HIST  is 

entry  WRITE (REC  s  ENTRY_SET; 

STATUS:  out  HIST_STATUS) ; 
end  ENTER_HIST; 

—  USED  TO  WRITE  A  RECORD  OR  SET  OF  RECORDS  ON  THE  HISTORY 

procedure  SEARCH_LOG (SER_NO  :  EXT  SERIAL  NO; 

REC~:  out  ENTRY_SET7 
STATUS  :  out  HI ST_STATUS ) ; 

—  SEARCHES  LOG  FOR  THE  NEXT  LOG  ENTRY~FOR  A  PARTICULAR  EASN 

procedure  READ_LOG (REC  :  out  ENTRY  SET; 

STATUS  :  out  HIST  STATUS); 

—  READS  THE  NEXT  LOG  ENTRY  ~  MAY  SKIP  REFERENCE  ENTRIES 
procedure  REWIND_LOG; 

—  RESETS  LOG  TO  THE  BEGINNING  OF  THE  SHORT  HISTORY 

procedure  INIT_HISTORY; 

—  STARTS  A  FRESH  HISTORY 

procedure  NEW_DAY; 

—  CLOSES  PREVIOUS  DAY'S  HISTORY  AND  STARTS  NEW  DAY 

—  CLOSES  OLD  DAY'S  TAPE 

—  WRITES  CURRENT  RUNNING  AUDIT  ON  END  OF  OLD  DAY 
—  WRITES  CURRENT  RUNNING  AUDIT  ON  START  OF  NEW  DAY 
—  OPENS  NEW  DAY'S  TAPE 

—  AUDITS  OLD  DAY  TAPE  AND  COMPARES  WITH  RUNNING  AUDIT 
—  PRINTS  STATISTICAL  SUMMARY  OF  DAY'S  ACTIVITIES 

procedure  CLOSE_HISTORY; 

—  CLOSES  HISTORY  WITHOUT  STARTING  A  NEW  ONE 


HISTORY  OPS 


—  CLOSES  OLD  DAY'S  TAPE 

—  WRITES  CURRENT  RUNNING  AUpIT  TO  END  OF  TAPE 
—  AUDITS  TAPE  AND  COMPARES  WITH  RUNNING  AUDIT 
.  —  PRINTS  A  STATISTICAL  SUMMARY  OF  DAY'S  ACTIVITIES 

procedure  RE_ENTER_MESSAGES (LIST  s  MESSAGE_LIST; 

STATUS  :  out  HIST_STATUS; 
NOT_FOUND  :  out  MESSAGE_LIST) ? 

—  READS  A  LIST  OF  MESSAGES  FROM  HISTORY  INTO  INTRANSIT  AND 

—  PLACES  ON  QUEUE 

—  RETURNS  A  LIST  OF  MESSAGES  NOT  RECOVERED 

procedure  READ_MESSAGE (SER  NO  :  EXT_SERIAL_NO; 

PTR“s  out  MSG ID; 

QTiTMQ  •  nut  HTQT  9TAT!1<?\« 

—  READS  A  MESSAGE  INTO  INTRANSIT  AND  RETURNS  A  MSGID 


end  HISTORY  OPS; 


INTERFACE  TO  8254 


with  BYTE_DEF  ;  use  BYTE_DEF  ; 
package  INTERFACE  TO  8254  is 


INTERFACE_TO_8254 

interface- to- the  Intel  8254  counter/timer  IC 
Brian  G.  Sharpe 
14  June  1982 


--Name: 

— Purpose: 

—Programmer: 

--Date : 

—Description: 

—  This  package  provides  all  of  the  necessary  interfaces  to  the  Intel 

—  8254  counter/timer  IC.  The  necessary  byte  formats  are  defined  as 

—  types  and  subprograms  are  provided  in  order  to  provide  information 

—  hiding. 

—  This  package  is  not  complete;  basically,  only  those  subprograms 

—  that  are  required  have  been  defined  and  coded. 


H«*»*»****  NOTE  ****»*«*»» 

For  sake  of  simplicity,  memory-mapped  I/O  is  assumed  to  be  used. 
Use  of  non-memory-mapped  I/O  will  require  something  other  than 
SHARED  VARIABLE  UPDATE  in  order  to  read  and  write  to  the  hardware. 


--  declaration  section: 


type  TYPE_OF_COUNTING_FORMAT  is  (  BINARY,  BCD  ) ; 


—  The  following  modes  determine  the  operating  modes  of  the 

—  programmable  8254. 


type  PERMISSABLE_MODES  is 
(  M0DE_0, 

MODE  1, 

MODE- 2 , 

MODE- 3 , 

MODE  4, 

MODE  5  ) ; 


—  interrupt  on  terminal  count 

—  hardware  retriggerable  one-shot 

—  rate  generator 

—  square  wave  mode 

—  software  triggered  strobe 

--  hardware  trtiggered  strobe  (retriggerable 


type  PERMISSABLE  CHANNELS  OR  READ  BACK  is 

(  CHANNEL  0,  —  select  counter  channel  0 

CHANNEL- 1 , 

CHANNEL  2, 

READ  BA^K  );  —  select  read-back  command  mode 


subtype  PERMISSABLE_CHANNELS  is  PERMISSABLE  CHANNELS  OR_READ_BACK 

range  CHANNELjJ. .CHANNEr_2; 


type  CHANNEL  WORD  ARRAY  is  array(  CHANNEL  0  ..  CHANNEL  2  )  cf  WORD ; 
type  SELECT_EHANNrL_ARRAY  is  array(  CHANNlLJ)  ..  CHANNrL_2  )  of  BOOLEAN; 
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—  read  any  combination  of  the  three  16-bit  channels 
function  READ  MULTIPLE  CHANNELS 

T  READ_CH¥L  :  in  SELECT  CHANNEL  ARRAY  ) 
return  CHANNELJfORDjtffRAY ; 

—  get  the  clock  frequencies  of  the  given  channel 

function  CHANNEL_CLOCK_FREQ  (  CHANNEL^ NO  :  in  PERMISSABLE_CHAHNELS  ) 
return  FLOAT”  “ 

—  set  the  counting  format  (binary  or  BCD)  of  the  given  channel 
procedure  SET  COUNTING  FORMAT 

(  CHANNEL  10  :  in  PERMISSABLE  CHANNELS; 

COUNTIN$_FORMAT  :  in  TYPE_OF_COUflTING_FORMATS  ); 

—  set  the  operating  mode  of  the  given  channel 
procedure  SET  OPERATING  MODE 

(“CHANNEL  Nff  :  in  PERMISSABLE  CHANNELS; 

OPERATING  FORMAT  :  in  PERMISSABLE~MODES  ); 


end  INTERFACE  TO  825H; 


—  NAME:  MESSAGEJ5PS 

—  PURPOSE:  contains  data  dafinitions  and  operation  definitions 

dealing  with  the  message. 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  17,  1982 


type  BLOCK_COUNT  is  new  STRING (1. .3) ; 

type  ERR_STAT  is  (OK,END_OF  TEXT, LINK  ERROR, OTHER_ERROR ) ; 

type  FORMAT  is  (ACP,JANAP);” 

type  MESSAGE_CATEGORY  is  (NORMAL, SERVICE) ; 

type  NUM_RIS  is  range  0..50; 

type  PART_HEADER  is  private: 

type  PART__PTR  is  access  PART_HEADER; 

type  POSITION  is  limited  private; 

type  RI_STAT  is  (OK,LAST_RI , ERROR) ; 

type  SEG_ARRAY  is  array (NATURAL  range  <>)  of  SEGMENT; 
type  VERSION_HEADER  is  private; 
type  MSGID  is  access  VERSION_HEADER; 

function  ESTABLISH_VERSION (EASN  :  EXT  SERIAL  NO)  return  MSGID; 

—  ESTABLISH  A  MESSAGE  VERSION  HEADER” 

-  HEADER  HAS  NO  PARTS 

procedure  OPEN_FOR__READ (MESSAGE  :  MSGID; 

START  WITH  :  PARTJNAME; 

POS : out  POSITION); 

~  ESTABLISH  INITIAL  POSITION  FOR  READING  FROM  A  MESSAGE 

procedure  READ_CONTINUOUS (MESSAGE  :  MSGID; 

COUNT  :  in  out  CHAR_COUNT; 
WHERE_FROM  :  in  out  POSITION; 

TEXT  :  out  STRING; 

STATUS  :  out  ERR_STAT) ? 
procedure  READ_FROM_P ART (MESSAGE  :  MSGID; 

COUNT  :  in  out  CHAR  COUNT; 

WHERE_FROM  :  in  out”POSITION; 

TEXT  :  out  STRING; 

STATUS  :  out  ERR_STAT) ; 

—  READ  COUNT  CHARACTERS  STARTING  FROM  WHERE  FROM 

—  CHARACTERS  ARE  RETURNED  IN  TEXT 

—  IF  STATUS  IS  END  OF  TEXT,  COUNT  WILL  REFLECT  ACTUAL  NUMBER 

"  OF  CHARACTERS  READ 

—  CHECK  FOR  LINKING  ERRORS  AND  RETURNS  ERROR  IF  SEGMENTS 

—  ARE  NOT  LINKED  IN  A  CONSISTENT  FASHION 
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procedure  ATTACH  SEGMENT  (MESSAGE  :  MSGID;  SEG  :  SEG_PTR)-; 

—  ATTACHES  A  SEGMENT  TO  THE  MESSAGE  IN  THE  PART 

—  SPECIFIED  IN  THE  SEGMENT 

—  IF  NO  PART_HEADER  EXISTS,  ONE  WILL  BE  CREATED 

procedure  WRITE  TO_P ART (MESSAGE  :  MSGID; 

PART  :  PART  NAME; 

TEXT  :  STRING); 

~  WRITES  TEXT  TO  THE  MESSAGE  AND  PART  SPECIFIED 

—  CREATES  PART_HEADERS  AND  SEGMENTS  AS  REQUIRED 

procedure  ATTACH  PART (MESSAGE,  OLD_MESSAGE  :  MSGID; 

PART  ;  PART_NAME) ; 

—  MAKES  ADDITIONAL  USE  OF  PART  IN  OLD_MESSAGE  IN  THE  CURRENT 

—  MESSAGE 

—  INCREMENTS  USER_COUNT  IN  PART_HEADER 

procedure  FREE_PART (MESSAGE  :  MSGID;  PART  :  PART_NAME) ; 

—  DETACHES  AND  FREES  (IF  NO  OTHER  USE)  A  SPECIFIED  PART  FROM 

—  A  MESSAGE 

function  CALCULATE_BLOCK_COUNT  (MESSAGE  :  MSGID)  return  BLOCK__COUNT; 

—  CALCULATES  THE  NUMBER  OF  80  CHARACTER  OUTPUT  BLOCKS 

—  OCCUPIED  BY  A  MESSAGE 

—  RETURNS  THE  NUMBER  IN  STRING  FORM 

—  DOES  NOT  ALLOW  FOR  MCB 

procedure  SET_BLOCK_COUNT (MESSAGE  ;  MSGID;  COUNT  :  BLOCK_COUNT) ; 

—  SET  BLOCK  COUNT  IN  MCB 

task  FREE_VER  is 

entry  FREE_VERSION (MESSAGE  j  MSGID); 

—  FREES  HEADERS  AND  SEGMENTS  WHICH  ARE  NOT  IN  USE  BY  OTHER 
—  VERSIONS 
end  FREE_VER; 

function  READ  EASN (MESSAGE  :  MSGID)  return  EXT  SERIAL  NO; 

—  READ  EXTENDED  SERIAL  NUMBER 

procedure  SET_CATEGORY (MESSAGE  :  MSGID;  CATEGORY  :  MESSAGE_C ATEGORY ) 
function  READ"CATEGORY (MESSAGE  :  MSGID)  return  MESSAGE  CATEGORY; 

—  READ  AND  SET  MESSAGE  CATEGORY  (NORMAL  OR  SERVICE) 

procedure  SET_CLASS (MESSAGE  :  MSGID; 

CLASS  :  SECURITY_CLASSIFlCATION); 

function  READ  CLASS (MESSAGE  s  MSGID)  return  SECURITY_CLASSIFICATION; 

—  SET  AND  READ  SECURITY  CLASSIFICATION  OF  MESSAGE 

procedure  SET  NUM_RIS (MESSAGE  :  MSGID;  RI_COUNT  s  NUM_RIS) ; 


MESSAGE  OPS 


function  READ  NUM_RIS (MESSAGE  :  MSGIQ)  return  NUM  RIS; 

•  SET  AND  READ  THE  NUMBER  OF  RIS  ~ 

procedure  SET  TIME  OF_RECEIPT (MESSAGE  s  MSGID;  TOR  :  DATE  TIME) ; 
function  READ” TIME~OF_RECEIPT (MESSAGE  :  MSGID)  return  DATEJTIME; 

—  SET  AND  READ  TIME  OF  RECEIPT 

procedure  SET  PRECEDENCE (MESSAGE  :  MSGID;  PREC  :  PRECEDENCE); 
function  READ”PRECEDENCE (MESSAGE  :  MSGID)  return  PRECEDENCE; 

~  SET  AND  READ  PRECEDENCE 

procedure  SET_LOGICAL  LINE (MESSAGE  :  MSGID; 

LINE  NUMBER  :  LOGICAL  LINE); 

function  READ_LOGICAL_LINE (MESSAGE  :  MSGID)  retuTn  LOGICAL_LINE; 

—  SET  AND  READ  LOGICAL  OUTPUT  LINE  NUMBER 

procedure  SET_CHAR_TYPE (MESSAGE  :  MSGID;  SET  s  CHAR_SET_TYPE) ; 
function  READ”char"tYPE (MESSAGE  s  MSGID)  return  CHAR  SET_TYPE; 

~  SET  AND  READ  CHARACTER  SET  TYPE 

procedure  SET__FORMAT (MESSAGE  :  MSGID;  FMT  :  FORMAT); 
function  READ”FORMAT (MESSAGE  s  MSGID)  return  FORMAT; 

—  SET  AND  READ  MESSAGE  FORMAT 

procedure  FIND_CLASS (MESSAGE  :  MSGID; 

CLASS  :  out  STRING; 

ERROR  :  out  BOOLEAN); 
procedure  FIND_LMF( MESSAGE  :  MSGID; 

LMF  :  out  STRING; 

ERROR  :  out  BOOLEAN); 

—  RETURN  THE  DESIRED  PORTION  OF  THE  HEADER 

procedure  FIND_FIRST_RI (MESSAGE  s  MSGID; 

POS  :  out  POSITION; 

STATUS  ;  out  RI  STAT) ; 

—  RETURNS  THE  POSITION  OF  THE  FIRST  RI  IN  A  MESSAGE 

procedure  FIND_RI (MESSAGE  :  MSGID; 

POS  :  in  out  POSITION; 

RI  :  out  STRING; 

STATUS  :  out  RI_STAT) ; 

—  CALLED  WITH  POS  POINTING  TO  AN  RI 

—  RETURNS  THAT  RI  AND  SETS  POS  TO  NEXT  RI 

function  NUM  SEGMENTS (MSG  :  MSGID; 

PART  s  PART  NAME)  return  SEGMENT__NUMBER; 

—  RETURNS  THE  NUMBER  OF  SEGMENTS”lN  A  PART  OF  A  MESSAGE 

procedure  GET  PART (MSG  :  MSGID; 

“  PART  s  PART  NAME; 


MESSAGE  OPS 


SEGS  :  out  SEG  ARRAY); 

—  READS  THE  SEGMENTS  OF  A  PART  INTO  THE  ARRAY  SEGS  FOR  USE  BY  HISTORY 

function  GET  is  new  GET  INTRANSIT (PART_HEADER, PART  PTR) ; 
function  GET  is  new  GET~INTRANSIT (VERSION  HEADER, MSGID) ; 
procedure  FREE  is  new  FREE_INTRANSIT (PART- HEADER,PART  PTR); 
procedure  FREE  is  new  FREE_INTRANS IT (VERS ION_HEADER, MSGID ) ; 

—  GET  AND  FREE  STORAGE  FOR  VERSION_HEADERS  AND  PART  HEADERS 

—  IN  THE  INTRANSIT  STORAGE  AREA.  SEE  MANAGE_STORAGE  FOR  DETAILS. 

private 

type  USER  COUNTER  is  range  0..50; 
type  PART_HEADER  is 
record 

FIRST^S EGMENT  :  SEG_PTR; 

AST_SEGMENT  s  SEG_PTR; 

SEGMENT_COUNT  :  SEGMENT_NUMBER; 

PART  :  PART_NAME; 

USER_COUNT  s  USER_COUNTER; 
end  record; 

type  PARTS_ARRAY  is  array(PART  NAME)  of  PART  PTR; 
type  VERSION_HEADER  is  “  “ 

record 

CATEGORY  :  MESSAGE  CATEGORY; 

CHAR_TYPE  s  CHAR  SET  TYPE; 

CLASS  :  SECURITY""CLASSIFICATION; 

EASN  .  EXT_SERIAL_NO; 

FMT  ;  FORMAT; 

LOGICAL_OUTPUT__LINE  j  LOGIC AL_LINE; 

PREC  ;  PRECEDENCE; 

RI__COUNT  s  NUM  RIS; 

SECTIONS  ;  PARTS  ARRAY; 

TIME_OF_RECEIPT  s  DATE_TIME; 

end  record; 
type  POSITION  is 
record 

SEG  :  SEG_PTR; 

COUNT  :  CHAR_COUNT; 
end  record; 
end  MESSAGE  OPS; 


SERVICE  MESSAGE  OPS 


with  RI_OPS ,  MESSAGE_OPS ,  GLOBAL_TYPES;  use  RI_OPS,  MESSAGE_OPS, 
GLOB AL_TYPES ; 

package  SERVICE_MESSAGE_OPS  is 


—  NAME:  SERVICE_MESSAGE_OPS 

~  PURPOSE:  contains  data  definitions  and  operations  required  for 
—  generating  service  messages. 

II  —  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  17,  1982 


type  SVC_MSG_TYPE  is  (ALL_RI  INVALID,  EXCESSIVE_ROUTING_REJ, 
HI_JPREC_ACC ,  ILLEGAL  EXCHANGE,  INCORRECT_CSN , 
INPUT_SCTY_MISMATCH,  INVALID_BLOCK_COUNT ,  INVALID_EOM_ACC , 
"  INVALID_EOM_REJ,  INVALID_HEADER  ACC,  INVALID_HEADER_REJ , 

invalid_ri,"invalid_ri_f!eld,  invalid_scty  field, 

INVALID_TI_ACC,  INVALID__TI_REJ ,  NO_EOM,  OPEN_CSN, 
OUTPUT_SCTY_MISMATCH,  SUSPECTED  STRAGGLER, 
SUSPENDED_TRANSMISSION,  TRAFFIC~CHECK ,  TWO_CONSEC  SOM) ? 

*“  type  SVC_MSG_INFO  is 

record 

MSG_REF:MSGID; 

MSG_TYPE : SVC_MSG_TYPE ; 

RIS:RI_PTR; 

LOW_CSN:CSN; 

ft  HIGH__CSN:CSN; 

end  record; 

task  type  GEN_SVC  is 

entry  GENERATE_SVC_MESSAGE (INFO:SVC_MSG_INFO) ; 
end  GEN_SVC; 

P  end  SERVICE  MESSAGE  OPS; 
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TASKS 


with  PHYSICAL_PORT, MANAGE  TRANSLATED  QUEUES; 
use  PHYS IC  AL__PORT ,  MANAGE_TRANSLATED__QUEUES ; 

package  TASKS  is 


NAME:  TASKS 

PURPOSE:  Data  structure  used  to  correlate  tasks  with  the  line  number 
of  the  physical  line  they  are  servicing. 


type  OUTPUT_PTR  is  access  OUTPUT_MESSAGE; 
type  SEND_XI_IV_PTR  is  access  SEND_MODE_II_IV; 
type  SEND_V_PTR  is  access  SEND_MODE_V ; 
type  SEND_I_PTR  is  access  SEND_MODE  1? 
type  CONTROL_PTR  is  access  CONTROL_CHARACTER; 

type  TASK_LIST  is 
record 

HANDLER:  MANAGER; 

OUTPUT:  OUTPUT_PTR; 

SEND_II_IV:  SEND_II_IV_PTR; 

SEND_V :  SEND_V_PTR; 

SEND_I:  SEND_I_PTR; 

GENCC , RECVCC :  CONTROL_PTR; 
end  record; 

TABLE:  array  (  PHYSICAL_LINE  )  of  TASK_LIST; 
end  TASKS; 
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with  GLOBALJTYPES;  use  GLOBALJTYPES ; 
package  TIME_OPS  is 


—  NAME:  TIMEJDPS 

—  PURPOSE:  provides  operations  on  the  type  DATE_TIME 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  14,  1982 


function  READ_ CLOCK  return  DATE  TIME; 

—  READS  THE  SYSTEM  TIME  AND  CONVERTS  IT  TO  A  JULIAN  DATE_TIME 

function  "<"  (Tl,  T2  :  DATE_TIME)  return  BOOLEAN; 
function  "<«"  (Tl,  T2  :  DATEJTIME)  return  BOOLEAN; 
function  ">"  (Tl,  T2  :  DATEJTIME)  return  BOOLEAN; 
function  ">■"  (Tl,  T2  :  DATEJTIME)  return  BOOLEAN; 

—  provide  comparison  facilities  for  the  Julian  DATEJTIME  type 
end  TIME  OPS; 
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3.2  Package  Specification  Dependencies 

The  chart  in  Figure  3.2-1  illustrates  the  package  specification 
dependencies.  This  is  especially  useful  if  a  package  must  be 
recompiled,  since  the  chart  shows  which  other  packages  must  also 
be  recompiled.  Any  package  to  the  right  of  the  one  being 
recompiled  that  is  connected  by  a  ircle  must  also  be  recompiled. 
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Figure  3.2-1  Package  Specification  Dependencies 


3.3  Traceability  Matrix 


The  following  section  shows  forward  and  backward  traceability. 
The  forward  direction  is  from  the  Requirements  Specification 
to  the  Functional  Decomposition  Charts  illustrated  in  Section 
2.4  of  this  document.  Reverse  traceability  is  the  opposite 
of  the  above  process. 
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rORWARD  TRACEABILITY 


REQUIREMENT 


DESIGN  MODULE 


All 
A 1 2 1 
A1 22 
A 1 3 1 
A1321 
A 1322 

A 1 33 1 

A1332 

A134 

A31 1 

A312 

A313 

A3141 

A3142 

A3143 

A3143 

A3144 

A3 1 5 1 

A3152 

A3153 

A3154 

A3 1 54 

A3155 

A3156 

A3157 

A3161 

A3161 

A3162 

A3162 

A3163 

A3 1 63 

A3164 

A3164 

A3165 

A3166 

A32 

A331 

A3321 

A3321 

A3322  (A3343) 

A3323  (A3332, A3344 , A3354) 
A3324  (A3334,A3345,A3354) 
A3325  (A3346) 

A3331 
A3332 
A3333 
A3333 
A3334 
A  3  3  4 1 
A3342 


RUN  SWITCH 

AUDIT. AUDIT  INTRANSIT 
HISTORY_OPS . RE_ENTER_MESSAGES 
MONITOR  HARDWARE  ERRORS 
AUDIT. AUDIT  OVERFLOW 
RUN  SWITCH 

AUDIT. AUDIT_INTERCEPT 
RUN  SWITCH 

MONITOR  HARDWARE  ERRORS 

BUILD  MESSAGE  FROM  SEGMENTS 

BUILD_VALID_AlYNCH_SEG.RECEIVE_CHARS 

BUILD  SYNCH_SEGMENT.RECEIVE_CHARS 

FORMAT  ASYNCH  SEGMENT 

RECOGNIZE  STAl?T_OF_MESSAGE 

FORMAT  ASYNCH  SEGMENT 

RECOGNlZE_ENDlNG_SEQUENCE 

PROCESS_CONTROL_SEQUENCE 

BUILD  SYNCH  SEGMENT 

IDENTIFY  1ST  CHARACTER 

VALIDATE  2ND  CHARACTER 

build_sy¥ch_Ieg 

INTERPRET  CC 
VALIDATE  S3RD  CHARACTER 
INTERPRET  CC  ” 

CHECK  BLK  PARITY 

validate  First  segment 

SET  ECSN” 

CHE^K  MODE  II_IV_CSN 
READ/SET  E/RCSN 
CHECK  MOffE_V_CSN 
READ/SET  ECSN 
VALIDATE  FIRST_SEGMENT 
READ  CHNL_DES 
COMPlETE  TI 

RECOGNIZE_ENDING_SEQUENCE 

GENERATE_CONTROL_CHARACTERS 

VALIDATE  MESSAGE 

CHECK  JAFAP  HEADER 

READ  SECURlTY_PROSIGN 

CHECF  RECORD_COUNT 

CHECK  RIS 

CHECK  EOM 

CHECK_EOT 

CHECK  ACP  HEADER 

CHECK  RIS 

COMPLETE  ACP  HEADER 
READ  SECURITY_PROSIGN 
CHECF  EOM 
CHECK_LMF 
CHECK  HP J  HEADER 
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FORWARD  TRACEABILITY 


REQUIREMENT 

DESIGN  MODULE 

A3342 

READ  SECURITY  PROSIGN 

A3343 

check  record  Gount 

A3344 

CHECK  RIS 

A3345 

CHECK-EOM 

A3346 

CHECK  EOT 

A3351 

CHECK- HPA  HEADER 

A3352 

CHECK  RIS 

A3353 

COMPLETE  HPA  HEADER 

A3353 

READ  SECURITY  PROSIGN 

A3354 

CHECK  eom 

A341 

PROCESS  MCB 

A342 

BUILD  JlNAP  MCB 

A343 

BUILD  ACP  MCB 

A344 

MODIFY  MCI 

A345 

COMPLETE  MCB 

A35 

GENERATE  SERVICE  MESSAGE 

A361 

STORE  REFERENCE 

A361 

PROCESS  MCB 

A361 

manage  Overflow. move  to  overflow 

A361 

QUEUE  KORM  MSG  BY  PRECEDENCE 

A361 

QUEUE  SVS  ESG  BY  PRECEDENCE 

A361 

HISTORY  OFS.EKTEK  HIST. WRITE 

A362 

MANAGE  INTRANSIT. CALCULATE  THRESHOLD 

A363 

MANAGE  OVERFLOW. RECOVER  OVERFLOW 

A363 

MANAGE- MESSAGE  QUEUES. QUEUE  REINTROD 

A363 

HISTORY  OPS. ENTER  HIST.WRITl  HISTORY 

A364 

RETRV  NfXT  MSG  FOl  PROCESSING 

A364 

QUQUE  FROM  FROlT  - 

A411 

GET  RTS 

A412 

GET  RIS 

A4 1  3 

SEGREGATE  ROUTING  LINE 

A41 3 

GET  RIS 

A421 

TRANSLATE  MESSAGE 

A4221 

TRANSLATE  MESSAGE 

A4222 

CONVERT  TG  JANAP 

A4223 

CONVERT- TO- ACP 

A4224 

translate  Message 

A4225 

REMOVE  DBLS 

A4231 

TRANSLATE  MESSAGE 

A4232 

TRANSLATE- TO  ASCII 

A4233 

TRANSLATE  TO  ITA  2 

A4234 

TRANSLATE- MElSAGl 

A4235 

TRANSLATE  TO  CARD 

A4236 

TRANSLATE  FRGM  CARD 

A4237 

TRANSLATE-MESSlGE 

A4238 

FILL  LAST- BLOCK 

A431 

MANAGE  TRANSLATED  MESSAGE  QUEUES 

A432 

MOVE  FlOM  INTERCElT  TO  INTRANSIT 

A433 

RETRIEVE  NEXT  MESSAGE  - 

A433 

QUEUE  FROM  FRONT 
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FOR  *RD  TRACEABILITY 


REQUIREMENT 

A511 

A512 

A513 

A513 

A514 

A514 

A514 

A515 

A531 

A5321 

A5322 

A5323 

A533 

A541 

A5411 

A5411 

A5412 

A5412 

A5413 

A5413 

A5414 

A5414 

A5421 

A5421 

A5422 

A5422 

A5423 

A5423 

A5424 

A5424 

A5425 

A5425 

A5426 

A5426 

A543 

A543 

A551 

A552 

A553 

A554 

A555 

A556 

NON  FUNCTIONAL  REQUIREMENTS 
I. SENTENCE  1 
I. SENTENCE  1 
I. SENTENCE  2 

I.  A  A  B 

II.  A. (1) 

II. A. (2) 


DESIGN  MODULE 

MESSAGE  OPS. READ  CONTINUOUS 

VALIDATf_RI 

VALIDATE  LMF 

FIND  LMF 

VALIDATE  SECURITY 
READ  LOGICAL  LINE 
FIND-CLASS  ” 

SEND” ASYNCH 

gen  Frame  chars 
fraHe  bloSk 

FRAME” BLOCK 
FRAME  block 
OUTPUT  MESSAGE 

send_sYnch 

SEND  SYNCH 

TRANSMIT  SYNCH  SYNCH 
SEND  SYNSH 

TRANSMIT  SYNCH  CHARS 
SEND  SYNSH 

TRANSMIT  SYNCH  CHARS 
SEND  SYNSH 

TRANSMIT  SYNCH  CHARS 
GENERATES  CONTROL  CHARS 
RECEIVED  CONTROL  SHARS 
GENERATES  CONTROS  CHARS 
RECEIVED  SONTROL  SHARS 
GENERATES__CONTROt  CHARS 
RECEIVED  CONTROL  SHARS 
GENERATES  CONTROS_CHARS 
RECIEVED  SONTROL  CHARS 
GENERATES  CONTROS  CHARS 
RECEIVED  SONTROL  SHARS 

generateS_control_chars 

RECEIVED_CONTROL  CHARS 
OUTPUT  MEf  AGE 
READ  CHANNEL_MODE 
HISTORY  OPS. ENTER_HIST. WRITE 
HISTORY”OPS.ENTER_HlST. WRITE 
HISTORY_OPS . ENTER_HIST .WRITE 
HISTORY”OPS.ENTER_HIST. WRITE 
HISTORY  OPS. ENTER  HIST. WRITE 
HISTORY” OPS. ENTER” HIST.WRITE 


RECEIVE  VALID  MESSAGE 
MANAGE  WESSAGF  QUEUES 
THROTTlE  INPUT” 
RECEIVE_SHARS 
RECEIVE”CHARS 
EVERYTHING 
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FORWARD  TRACEABILITY 


REQUIREMENT 


DESIGN  MODULE 


II. A. (3) 

II. A. (4) 

II. A. (5) 

II. A. (6) 

II. A. (7) 

II. A. (8) 

II. A. (9) 

II. A. (10) 

II. A. (11) 

II. A. (12) 

II.B.(I) 

II.  B. (2) 

III. A.O)  4  (2) 

III.A.(I)  4  (2) 

III.A.O) 

III.B.(I)  4  (2)  4  (3) 

III. B.(I)  4  (2)  4  (3) 

IV.  A. (1)  4  (2) 

IV. B.(I)  4  (2) 

V.  SENTENCE  1 

V. SENTENCE  2 
V. SENTENCE  3 
V. SENTENCE  4 
V. SENTENCE  5 

V.  SENTENCE  6  (DISTRIBUTION) 

VI. 

VII. 

IX. 

X. 

XI. 


RECEIVE  CHARS 
RECEIVE- CHARS 
BUILD  VALID  SYNCH  SEG 
BUILD- VALID  SYNCH_SEG 
FORMAT  SYNCJT  SEG 
FORMAT-SYNCH-SEG. RECEIVE  CHAR 
PROCESS  MCB 
RECEIVE- CHAR 

format  Synch  seg. receive  char 

FORMAT- SYNCH- SEG . RECEIVE- CHAR 
FORMAT'S YNCH-SEG. RECEIVE  CHAR 
SAME  AS  II.ATd)  -  II. A. Til) 

BUILD  VALID  ASYNCH  SEG. RECEIVE  CHAR 
XMIT  XSYNCH_CHAR  - 

the  Whole  switch 

BUILD  VALID  ASYNCH  SEG. RECEIVE  CHAR 

XMIT  XSYNCH  CHAR 

RECElVE_CHAl  AND  XMIT_CHAR 

RECEIVE_CHAR  AND  XMIT  CHAR 

SEGMENT  OPS 

NOT  APPUlCABLE 

PACKAGE  MANAGE  INTRANSIT 

NOT  APPLICABLE- 

NOT  APPLICABLE 

NOT  APPLICABLE 

UNDETERMINABLE  AT  THIS  TIME 

UNDETERMINABLE  AT  THIS  TIME 

RI_0PS 

MANAGE_INTRANSIT 
UNDETERMINABLE  AT  THIS  TIME 


CONCURRENCY  CHART  DESIGN  DOCUMENT  COMPONENT 


STARTUP/RECOVERY 
ASSEMBLE  MESSAGES 
PROCESS  MESSAGES 
TRANSMIT  MESSAGES 
OPERATOR  INTERFACE 


RUN  SWITCH 

RECEIVE  VALID  MESSAGE 
PROCESS  MESSAGE 
OUTPUT  MESSAGE 
MONITOR  SWITCH 


I 

I 


BACKWARD  TRACEABILITY 


D.I.r  DESIGN  IMPLEMENTATION 


ADDJTEXT 
ASH. GET 

ASYNCH_SEG . RECOGNIZE_END_OF_PART 

AUDIT. AUDIT  INTERCEPT 

AUDIT . AUDIT“INTRANSIT 

AUDIT. AUDIT  OVERFLOW 

BUILD  ACP  M?B 

BUILD_JANlP  MCB 

BUILD_MESSASE  FROM  SEGMENTS 

BUILD_SYNCH  SlG 

BUILD_SYNCH_SEGMENT 

BUILD_SYNCH_SEGMENT . RECEIVE_CHARS 

BUILD_VALID  ASYNCH_SEG. RECEIVE  CHAR 

BUILD_VALID_ASYNCH_SEG.RECEIVE“CHAR 

BUILD_VALID  ASYNCH  SEG. RECEIVE  CHARS 

BUILD_VALID  SYNCH  SEG 

BUILD_VALID  SYNCH_SEG 

CHECK_ACP  HEADER 

CHECK  BLK  PARITY 

CHECK_EOM“ 

CHECK~EOT 
CHECK  HPA  HEADER 
CHECK_HPJ“HEADER 
CHECK_ICD 

CHECK_JANAP_HEADER 

CHECK_LMF 

CHECK_MODE  II  IV  CSN 
CHECK  MODE  V  ?SN~ 

CHEC^RECOTrD- COUNT 
CHECK  RIS 
CHECK  RIS 

complFte_acp_header 

COMPLETE~HPA  HEADER 
COMPLETE_MCB” 

COMPLETE  TI 
CONVERT_TO  ACP 
CONVERT  TO~JANAP 
DEQUEUE_MSC_FOR_OVERFLOW 

FILL_LAST  BLOCK 
FIND_CLAS3 
FIND  LMF 

FORMlT_ASYNCH  SEGMENT 
FORMAT  ASYNCH  SEGMENT 
FORMAT”SYNCH  ?EG 


D.I.-  A3143,  A3152,  A3153,  A3 1 54 
Fulfills  requirement  that  unique  ASN  is 
assigned  to  each  incoming  message. 

D. I. -breaks  the  transmission  identifier 
of  asynch  messages  into  segment. 

A 1 33 1 
A121 
A 1 32 1 
A343 
A342 
A3 1 1 
A3154 
A  3 1 5 1 
A3 1 3 

III.B.(I)  &  (2)  &  (3) 

III . A. ( 1 >  &  (2) 

A312 
II. A. (5) 

II. A. (6) 

A3331 

A3157 

A3324,A3334,A3345,A3354 

A3325.A3346 

A3  35 1 

A3342 

A3164 

A3321 

A  3  3  4 1 

A3 1 62 

A3 1 63 

A3322,A3343 

A3352 

A3323,A3332,A3344,A3354 

A3333 

A3353 

A345 

A3 1 65 

A4223 

A'<222 

Implicit  requirement-  lower  precedence 
messages  overflow. 

A4238 
A514 
A513 
A  3 1 4  3 
A  3 1 4 1 
II. A. (7) 
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I 


BACKWARD  TRACEABILITY 


DESIGN  MODULE 

FORMAT  SYNCH_SEG. RECEIVE_CHAR 
FORMAT- SYNCH_SEG. RECEIVE_CHAR 
FORMAT_SYNCH_SEG.RECEIVE_CHAR 
FORMAT  SYNCH_SEG.RECEIVE_CHAR 
FRAME_fLOCK  “ 

FRAME_BLOCK 

FRAME_BLOCK 

GENERATED_CONTROL_CHARS 

GENERATED_CONTROL_CHARS 

GENERATED  CONTROL  CHARS 

GENERATED  CONTROL  CHARS 

GENERATED_CONTROL  CHARS 

GENERATED  CONTROL_CHARS 

GEN£RATE_?ONTROL  CHARACTERS 

GENERATE  SERVICE-MESSAGE 

GEN_FRAMr_CHARS 

GET_RIS 

GET_RIS 

GET_RIS 

GET  SEG 

HISTORY_OPS.ENTER_HIST. WRITE 
HISTORYJDPS. ENTER  HIST. WRITE 
HISTORY_OPS. ENTER  HIST. WRITE 
HISTORY_OPS. ENTER  HIST. WRITE 
HISTORY  OPS. ENTER  HIST. WRITE 
HISTORY_OPS. ENTER  HIST. WRITE 
HISTORY_OPS. ENTER  HIST. WRITE 
HISTORY_OPS. ENTER  HIST. WRITE  HISTORY 
HISTORY  OPS.  RE  ENTER  MESSAGES’ 
IDENTIFY  1 st_cWaractEr 
INTERPRET_CC 
INTERPRET  CC 

manage_inTransit 

MANAGE  INTRANSIT. CALCULATE  THRESHOLD 
MANAGE_MESSAGE  QUEUES 
MANAGE_MESSAGE  QUEUES. QUEUE  REINTROD 
MANAGE_OVERFLOW . MOVE  TO  OVElFLOW 
MANAGE_OVERFLOW. RECOVER  OVERFLOW 

manage_translated_messaSe  QUEUES 

MANAGE  TRANSLATED  MESSAGE-QUEUES 
MESSAGf_IO 

MESSAGE_OPS. ATTACH  SEGMENT 
MESSAGE-OPS.CALCULlTE_BLOCK_COUNT 

MESSAGE_OPS. ESTABLISH  VERSION 
MESSAGE  OPS. FREE  PART 
MESSAGE-OPS . READ-CONTINUOUS 
MESSAGE- OPS . SET  ?LOCK  COUNT 
MESSAGE- OPS  OPETr  FOR  ffEAD 
MESSAGE- OPS  READ  CONTINUOUS 


REQUIREMENT 


’•I 


II. A. (8) 

II. A. (11) 

II. A. (12) 

II.B.O) 

A5323 

A5321 

As>322 

A5425 

A5421 

A5422 

A5426 

A5423 

A5424 

A32 

A35 

A53 1 

A41 3 

A41 1 

A412 

D.I.-  break  messages  into  segments. 

A361 

A555 

A551 

A554 

A552 

A553 

A556 

A363 

A122 

A3152 

A3 1 54 

A3 1 56 

X. 

A362 

I. SENTENCE  1 

A363 

A3  6 1 

A363 

A431 

A433 

Reads/writes  to  hardware  file  (tape, 
disk,  virtual  memory). 

D.I.-of  internal  storage  of  messages 
D.I.-of  message  block  counts 


D.I.-of  internal  storage  of  message 
D.I.-of  internal  storage  of  messages 


A51 1 
Req.  to 
D.I.-of 
D.I.-of 


keep  block  count  in  MCR  update  * 
internal  storage  of  messages 
internal  storage  of  messages 
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I 

I 


BACKWARD  TRACEABILITY 


DESIGN  MODULE 
MODIFY_MCB 

MONITOR  HARDWARE  ERRORS 
MONITOR  HARDWARE  ERRORS 
MOVE_FROM  INTERCEPT^ TO_INTRANSIT 

move"to_i¥tercept 

MSG_DPS.FREE_VERSION 
MSG_OPS.READ  CATEGORY 

msg_ops.read_precedence 

MSG  OPS. READ  TIME  OF  RECEIPT 

MSG_OPS.SET  DATEGDRY 

MSG  OPS. SET  PRECEDENCE 

MSG  OPS. SET  TIME  OF  RECEIPT 

NOTlFY_OPERlTOR 

OUTPUT_MESSAGE 

OUTPUT  MESSAGE 

PACKAGE  MANAGE  INTRANSIT 

PROCESS_CONTROl_SEQUENCE 

PROCESS_MCB 

PROCESS  MCB 

PROCESS_MCB 

PROCESS  MESSAGE 

QUEUE_FlTOM  BACK 

QUEUE_MSG  BY  PRECEDENCE  AND  BY  TOR 
QUEUE  NORff  MSG  BY  PRECEDENCE  ~ 
QUEUE  ON  FlfONT-  ~ 

QUEUE_ON  F  BACK 

QUEUE  SVS  MSG_BY  PRECEDENCE 

read_cateDory 

READ  CHANNEL_DES 
READ-CHANNEL  MODE 
READ_CHAR  SET 
READ  CLASS 
READ  EASN 
READ“ECSN 

READ_FORMAT 

READ_LOGICAL_LINE 

READ_RCSN 

READ  SECURITY_PROSIGN 
READ  TOR 
READY_LINE_NO 

RECEIVED_CONTROL_CHARS 
RECEIVED-CONTROL_CHARS 
RECEIVED_CONTROL_CHARS 
RECEIVED  CONTROL- CHARS 
RECEIVED- CONTROL  CHARS 

receiveJThar 

RECEIVE_CHAR  AND  XMIT  CHAR 
RECEIVE  CHAR  AND  XMIT- CHAR 
RECEIVE  CHARS 


REQUIREMENT 

A344 

A134 

A131 

A432 

Partially  fulfills  A431 

D.I.-  removes  outdated  messages 

Part  of  requirement  of  A364 

Part  of  requirement  of  A364  and  A433 

Part  of  requirement  of  A364  and  A433 

Part  of  requirement  of  A364 

Part  of  requirement  of  A364  and  A433 

Part  of  requirement  of  A364  and  A433 

Implementation  of  'Notify  Operator' 

A543 

A533 

V. SENTENCE  3 

A3144 

A341 

II. A. (9) 

A361 

Control  of  A4 
Implicit  requirement 
Partially  fulfills  A431 
A361 

Implicit  requirement 

A361 

A361 

D.I.  to  accomplish  multiple  routing 
A3164 

D.I.  to  make  decision  of  A543 

D.I.  to  accomplish  multiple  routing 

D.I.  to  accomplish  multiple  routing 

D.I.  to  accomplish  multiple  routing 

A3 1 62 ,  A3 1 63 

D.I.  to  accomplish  multiple  routing 

A514 

A31 63 

A3321,A3333,A3342,A3353 
D.I.  to  accomplish  multiple  routing 
D.I.-  sets  line  status  to  'ready' 
for  next  message  transmission. 
A5426 
A5425 
A5421 
A5422 
A5423 
II. A. (10) 

IV.B.(I)  &  (2) 

IV. A. (1)  4  (2) 

II. A. (3) 
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« 

I 


BACKWARD  TRACEABILITY 


DESIGN  MODULE 

RECEIVE_CHARS 
RECEIVE_CHARS 
RECEIVE  CHARS 
RECEIVE_VALID_MESSAGE 
RECEIVE  VALID  MESSAGE 

recieveTJ  cont!Fol_chars 

RECOGNIZT_ENDING_SEQUENCE 
RECOGNIZE  ENDING  SEQUENCE 
RECOGNIZE  START  SF  MESSAGE 
REFLECT  STATUS  ~  " 

REMOVE  DBLS 
RESET  5EG 

RETRIEVE  NEXT  MESSAGE 

RETRV  NEXT  MSS  FOR  PROCESSING 

RI  OPS  “  "  “ 

Rl“OPS.FIND_FIRST_RI 

RI_OPS.FIND  RI 

RI  OPS. READ  RI_TABLE 

ROUTE_MESSAGE 

RUN  SWITCH 

RUN  SWITCH 

RUN  SWITCH 

SCAN  FOR  COLLECTIVE  RIs 

segmTnt_5ps 

-uGMENT_OPS . NEXT  SEGMENT 

SEGMENT_OPS.PRIOf_SEGMENT 

SEGMENT_OPS . READ  CHARACTER  COUNT 

SEGMENT_OPS . READ_CHARS 

SEGMENT  OPS. READ  PART 

SEGMENT_OPS . READ- SEGMENT  NUMBER 

SEGMENT  OPS. READ  TIME 

SEGMENT~OPS.SET_FART 

SEGMENT  OPS. SET  SEGMENT  NUMBER 

SEGMENT_OPS . SET  TIME 

SEGMENT  OPS. WRITE  SPECIFIC 

SEGMENT  OPS.WRITE”TO  PART 

SEGREGATE  ROUTING  LllE 

SEND_ASYN^H 

SEND“SYNCH 

SEND  SYNCH 

SEND_SYNCH 

SEND_SYNCH 

SEND  SYNCH 

SETjfrVTEGORY 

SET_CHAR_SET 

SET  CLASS 

SET  ECSN 

SET  FORMAT 

SET~RCSN 

SETHTOR 


REQUIREMENT 

II. A. (1) 

II. A. (4) 

I. A  &  B 

D.I.-  removes  outdated  messages 

I. SENTENCE  1 

A5424 

A3 1 66 

A3 1 4  3 

A3142 

Part  of  control  of  A3 

A4225 

D.I. 

Partially  fulfills  A433 

A  364 

IX. 

D.I. 

Same  as  FIND__FIRST_RI 
D.I. 

Control  of  A41 

A1322 

All 

A1332 

Partial  implementation  of  A345 
V. SENTENCE  1 

D.I.  of  internal  storage  of  messages 
D.I.  of  internal  storage  of  messages 
D.I. 

D.I.  of  internal  storage  of  segments 
D.I. 

Implicit  requirement 
See  TIME_OPS.READ_CLOCK 
D.I. 

Implicit  requirement 

See  TIME  OPS . READ_CLOCK 

D.I.  of  Internal  storage  of  segments 

D.I.  of  internal  storage  of  messages 

A  4 1  3 

A5 1 5 

A5412 

A541 

A5414 

A  5  4 1 1 

A5413 

D.I.  to  accomplish  multiple  routing 

D.I.  to  accomplish  multiple  routing 

D.I.  to  accomplish  multiple  routing 

A3161,  A3 1 62 ,  A3 1 63 
D.I.  to  accomplish  multiple  routing 
A3 1 63 

D.I.  to  accomplish  multiple  routing 


BACKWARD  TRACEABILITY 


DESIGH  MODULE 

STORE  REFERENCE 
THROTTLE  INPUT 
TIME  OPS._READ_CLOCK 
TRAN3LATE_FR0M  CARD 
TRANSLATE_MESSlGE 
TRANSLATE_MESSAGE 
TRANSLATE_MESSAGE 
TRANSLATE  MESSAGE 
TRANSLATE_MESSAGE 
TRANSLATE_MESSAGE 
TRANSLATE  TO  ASCII 
TRANSLATE_TO  CARD 
TRANSLATE  TO-ITA  2 
TRANSMIT_3YN£H_CffARS 

..nNSMlT  SYNCH_CHARS 
TRANSMIT  SYNCH_CHARS 
TRANSMIT_SYNCH_SYNCH 
VALIDATE_2ND_CHARACTER 
VALIDATE  83RD_CHARACTER 
VALIDATE_ACP  MSG 
VALIDATE_FIR3T  -SEGMENT 
VALIDATE  HPA  MSG 
VALIDATED PJ  MSG 
VALIDATE- JANAP_MESSAGE 
VALIDATE- JANAP_MSG 
VALIDATE_LMF 
VALIDATE  MESSAGE 
VALIDATE- MESSAGE_HEADER 
VALIDATE  RI 
VALIDATE- SECURITY 
XMIT  ASYlCH_CHAR 
XMIT- ASYNCH  CHAR 


REQUIREMENT 
A3  6 1 

I. SENTENCE  2 

Implicit  requirement 

A4236 

A4237 

A4221 

A4234 

A42 1 

A4224 

A4231 

A4232 

A4235 

A4233 

A5412 

A5414 
A5413 
A541 1 
A3 1 53 
A3155 

Control  of  A333 
A 1 6 1 

Control  of  A335 
Control  of  A334 
A332 

Control  of  A332 

ASU 

A331 

Control  of  A51 

A512 

A514 

III.B.(I)  4  (2)  A  (3) 
III.A.(I)  A  (2) 


3.4  Data  Structures 


The  following  section  illustrates  the  detailed  structure  of 
the  site  dependent  database  tables. 

3.4.1  Line  Table  Operations 

The  table  in  this  section  is  used  by  the  message  switch 
software  to  determine  how  to  initialize  the  serial  data 
channel  hardware  and  the  proper  protocol  to  handle  the 
incoming  and  outgoing  messages. 
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with  GLOBALJTYPES;  use  GLOBAL_TYPESj 
package  LINE_TBL_OPS  is 


—  NAME:  LINE_TBL_OPS 

—  PURPOSE:  Data  structures  that  contain  the  information  describing 

—  the  characteristics  of  each  line,  and  the  subprograms  needed  to 

—  access  the  information.  (  Note:  All  accesses  must  use  CONTROL 
as  these  data  structrues  are  shared.  ) 


type  TRANSMISSION  MODE  is  (  SYNCH_BLK_BY_BLK ,  SYNCH_CONTINUOUS , 
ASYNCH_NORMAL,  ASYNCH_STEPPED  ); 
type  FORMATJTYPE  is  (  ANY,  JANAP,  ACP,  ACP_MOD  ); 
type  LEVEL_TYPE  is  range  5.. 8; 

VALID_LEVEL  :  array (  1..2  )  of  LEVEL_TYPE  :■  (  5,  8  ); 

type  PHYSICAL_LINE  is  range  0..50; 

type  LOOP_SPEED  is  delta  0.1  range  45.. 9600; 

VALID_SPEED  :  array(  1..12  )  of  LOOP_SPEED  :»  (  45,  50,  56.9,  74.2, 
75,  150,  300,  600,  1200,  2400,  4800,  9600  ); 
type  COMMUNITIES  SERVED  is  (  R,  U,  RU,  Y,  RY,  UY,  RUY  ); 
type  FIRSTJLINK  Is  new  BOOLEAN; 

MAX_N 0_R I S_PER_DEL I VERY  :  array  (  0..4  )  of  INTEGER  :=  (  50, 

500,  1,  6,  14  ) ; 
type  XTSJTYPE  is  new  BOOLEAN; 
type  SOM_SEQ  TYPE  is  (  FULL,  ABBREV  ); 
subtype  LMF  Is  STRING (  1..2  ); 
subtype  MEDIA  is  STRING (  1..1  ); 
type  MEDIAS  is  (  'A',  'T' ,  'C',  'Z'  ); 
type  DIRECTION_TYPE  is  (  BOTH,  INPUT,  OUTPUT  ); 
type  NO_STOP_BITS  is  range  1..2; 

type  SPEC_TERM_TYPE  is  (  ACCES,  INTERSWITCH,  TECHNICAL_CONTROL  ); 
type  PHYS_IDS; 

type  PHYS_PTR  is  access  PHYS_IDS; 
type  PHYS_IDS  is 
record 

PHYS_LINE:PHYSICAL_LINE; 

NEXT : PHYS_PTR  i-  null; 
end  record; 
type  LOGICAL_IDS; 

type  LOGICAL_PTR  is  access  LOGICAL  IDS; 
type  LOGICAL_IDS  is 
record 

LOG_LINE:  LOGICAL  LINE; 

NEXT:  LOGICAL_PTR_:»  null; 
end  record; 

procedure  APPEND  LINE (  LOG_LINE :  LOGICAL_LINE;  PHYS  LINE: 

PHYS ICAL_LINE  ); 

—  Add  a  physical  line  to  the  normal  list  of  lines  for  a  logical 

—  line. 
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procedure  DROP_LINE(  LOG_LINE:  LOGICAL__LINE;  PHYSJLINE: 

PHYSIC AL_LINE  )? 

—  Drop  a  physical  line  from  the  normal  list  o£  lines  for  a  logical 

line. 

procedure  APPEND_ALT(  LOG_LINE:  LOGICAL_LINE;  PHYS_LINE: 

PHYSICAL_LINE  ) ? 

—  Add  a  physical  line  to  the  alternate  list  of  lines  for  a  logical 

—  line. 

procedure  DROP_ALT  (  LOG_LINE;  LOGICAL  LINE?  PHYS_LINE: 

PHYSICAL_LINE  ); 

—  Drop  a  physical  line  from  the  alternate  list  of  lines  for  a 

—  logical  line. 

procedure  BEGIN_ALT(  LOG_LINEs  LOGICAL_LINE  )? 

Begin  using  the  alternate  list  of  lines, 
procedure  END_ALT(  LOG_LINE:  LOGICAL_LINE  )? 

—  Begin  using  the  normal  list  of  lines. 

function  IS_ALT(  LOG_LINE:  LOGICAL_LINE  )  return  BOOLEAN? 

—  Determine  if  the  alternate  list  of  lines  is  being  used, 
function  VALID_PHYS_LINE (  LOG  LINE:  LOGICAL_LINE?  PHYS_LINE: 

PHYSICAL  LINE  )  return  BOOLEAN? 

—  Determine  if  this  physical  line  is  in  the  list  of  lines 

—  being  used  by  this  logical  line, 
procedure  MAKE_AVAILABLE (  PHYS_LINE:  PHYSICAL_LINE  )? 

—  Mark  this  line  as  available  for  use. 
procedure  NOT_AVAILABLE (  PHYS_LINE:  PHYSICAL_LINE  )? 

~  Mark  this  line  as  not  available  for  use. 
function  IS_AVAILABLE (  LOG_LINE:  LOGICALJLINE  )  return  BOOLEAN? 

—  Determine  if  this  line  is  available  for  use. 

procedure  SET__LOGICAL (  LOG_LINE :  LOGICAL_LINE?  FORMAT:  FORMAT_TYPE? 
PREFERRED_LMF:  LMF?  LEVEL:  LEVEL  TYPE? 

COMMUNITY?  COMMUNITIES_SERVED?  XTS:  XTS_TYPE?  MAX_RIS:  INTEGER? 
CHARACTERISED  CHAR_SET_TYPE ?  SPEC_TERM:  SPEC_TERM_TYPE  )? 

—  Set  the  descriptive  characteristics  of  a  logical  line 
function  READ_FORMAT(  LOG_LINE:  LOGICAL_LINE  )  return  FORMAT_TYPE? 

—  Provide  the  format  for  this  logical  line. 

function  READ_F1EFERRED_LMF(  LOG_LINE:  LOGICAL_LINE  )  return  LMF; 

Provide  the  preferred  line  media  format  for  this  logical  line, 
function  READ_LEVEL (  LOG_LINE:  LOGICAL_LINE  )  return  LEVEL_TYPE? 

—  Provide  the  encoding  level  for  this  logical  line, 
function  READ  COMMUNITY (  LOG_LINE:  LOGICAL_LINE  )  return 

COMMUNITIES_SERVED? 

Provide  the  communities  served  by  this  logical  line, 
function  READ_XTS (  LOG_LINE:  LOGICAL_LINE  )  return  XTS_TYPE? 

—  Provide  the  XTS  of  this  logical  line. 

function  READ_MAX  RIS(  LOG_LINE:  LOGICAL  LINS  )  return  INTEGER; 

--  Provide- maximum  number  of  routing  Tndicators  permitted  in  a 

—  message  on  this  logical  line. 

function  READ  CHARACTER_SET (  LOG_LINE :  LOGIC*  LINE  )  return 
CHAR_SET_TYPE? 

—  Provide  the  character  set  used  on  this  logical  line. 
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function  READ_SPEC_TERM(  LOG_LINE:  LOGICAL_LINE  )  return 
SPEC_TERM_TYPE? 

—  Provide  the  SPEC  TERM  of  this  logical  line, 
procedure  SET_PHYSICAL (  PHYS_LINE :  PHYSICAL_LINE;  CHNL_MODE: 

C H ANN E L_MO D E ;  XMIT_MODE:  TRANSMISSION_MODE;  DIRECTION: 

DI RECTI ON_TYPE;  SECURITY:  SECURITY_CLASSIFICATION;  DESIGNATOR: 
CHANNEL_DES;  SOM_SEQ:  SOM  SEQ_TYPE ;  STOP  BITS: 

NO_STOP_BITS  ) ; 

Set  the  descriptive  characteristics  of  this  physical  line, 
procedure  SET_OCSN {  PHYS_LINE:  PHYSICAL_LINE;  OCSN:  CSN  ); 

—  Set  the  OCSN  for  this  physical  line, 
procedure  INCREMENT_OCSN (  PHYS_LINE:  PHYSICAL_LINE  ); 

—  Increment  the  OCSN  for  this  physical  line, 
procedure  SET_ECSN(  PHYS_LINE :  PHYSICAL_LINE;  ECSN:  CSN  ); 

Set  the  ECSN  for  this  physical  line, 
procedure  SET_RCSN(  PHYS_LINE:  PHYSICAL_LINE;  RCSN:  CSN  ); 

—  Set  the  RCSN  for  this  physical  line. 

procedure  INCREMENT_OCSN (  PHYS_LINE:  PHYSICAL_LINE;  OCSN:  CSN  ); 

Increment  the  OCSN  for  this  physical  line, 
procedure  INCREMENT_ECSN (  PHYS_LINE :  PHYSICAL_LINE ;  ECSN:  CSN  ); 

Increment  the  ECSN  for  this  physical  line, 
procedure  INCREMENT_RCSN (  PHYS_LINE :  PHYSICAL_LINE;  RCSN:  CSN  ); 

Increment  the  RCSN  for  this  physical  line, 
function  READ__CHANNEL_MODE  (  PHYS_LINE:  PHYSICAL  LINE  )  return 
CHANNEL_MODE; 

—  Provide  the  channel  mode  of  this  physical  line. 

function  READ_SECURITY_CLASSIFICATION {  PHYS_LINE:  PHYSICAL_LINE  )  return 
SECURITY_CLASSIFICATION; 

—  Provide  security  classification  of  this  physical  line, 
function  READ_TRANSMISSION_MODE (  PHYS_LINE :  PHYSICAL_LINE  )  return 

TR AN S M I S S I ON_MOD E ; 

—  Provide  transmission  mode  of  this  physical  line, 
function  READ_DIRECTION {  PHYS_LINE:  PHYSICAL_LINE  )  return 

DIRECTION_TYPE; 

Provide  transmission  direction  of  this  physical  line, 
function  READ  DESIGNATOR (  PHYS_LINE :  PHYSICAL_LINE  )  return 
CHANNEL_DES; 

—  Provide  channel  designator  of  this  physical  line. 

function  READ_SOM_SEQ (  PHYS_LINE:  PHYSICAL_LINE  )  return  SOM_SEQ_TYPE ; 

Provide  the  start  of  message  sequence  for  this  physical  line, 
function  READ_STOP_BITS (  PHYS_LINE:  PHYSICAL__LINE  )  return  NO_STOP_BITS ; 

Provide  the  number  of  stop  bits  used  on  this  physical  line, 
function  READ_OCSN <  PHYS_LINE:  PHYSICAL_LINE  )  return  CSN; 

~  Provide  current  value  of  OCSN  for  this  physical  line, 
function  READ_ECSN(  PHYS  I^INE :  PHYSICAL_LINE  )  return  CSN; 

Provide  current  vaTue  of  ECSN  for  this  physical  line, 
function  READ_RCSN {  PHYS_LINE :  PHYSICAL_LINE  )  return  CSN; 

Provide  current  value  of  RCSN  for  this  physical  line, 
procedure  SET_CURRENT_PRECEDENCE {  PHYS_LINE:  PHYSICAL_LINE; 

CURRENT  PRECEDENCE:  PRECEDENCE  ); 
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—  Record  the  precedence  of  the  message  passed  to  this  physical 

~  line  for  transmission. 

function  READ_CURRENT_PRECEDENCE {  PHYS  LINE:  PHYSICAL_LINE  ) 
return  PRECEDENCE; 

—  Provide  current  precedence  for  this  physical  line, 
procedure  SET_START_TIME (  PHYS_LINE:  PHYSICAL_LINE  ); 

~  Record  time  that  a  message  was  passed  to  this  physical  line 
for  transmission. 

function  READ_START_TIME (  PHYS_LINE:  PHYSICAL  LINE  )  return 
DATE_TIME; 

Provide  time  that  this  physical  line  was  last  passed  a 
--  message  to  transmit, 

procedure  SETJCNTERCEPT (  LOG_LINE:  LOGICAL_LINE; 

INTERCEPT_PRECEDENCE:  PRECEDENCE;  INTERCEPT_MEDIA :  MEDIA  ); 

Set  intercept  flags  for  specified  criteria, 
procedure  RESET_INTERCEPT (  LOG_LINE :  LOGICAL_LINE; 

INTERCEPT_PRECEDENCE :  PRECEDENCE;  INTERCEPT_MEDIA :  MEDIA  ); 

—  Reset  intercept  flags  for  specified  criteria, 
function  IS_INTERCEPT (  LOG_LINE:  LOGICAL_LINE; 

THIS_PRECEDENCE:  PRECEDENCE;  THIS_MEDIA:  MEDIA  )  return  BOOLEAN; 

—  Determine  if  specified  criteria  messages  are  to  be  intercepted. 

procedure  SET_KILL (  PHYS_LINE:  PHYSICAL_LINE  ); 

Set  kill  flag  for  this  physical  line, 
procedure  RESET_KILL (  PHYS_LINE :  PHYSICAL_LINE  ); 

—  Reset  kill  flag  for  this  physical  line. 

function  IS_KILL(  PHYS_LINE;  PHYSICAL_LINE  )  return  BOOLEAN; 

—  Determine  if  kill  flag  is  set  for  this  physical  line, 
procedure  SET_KILL_ON_EMPTY (  PHYS_LINE:  PHYSICAL_LINE  ); 

Set  kill  when  queue  empty  flag  for  this  physical  line, 
procedure  RESET_KILL_ON_EMPTY (  PHYS_LINE:  PHYSICAL_LINE  ); 

—  Reset  kill  when  queue  empty  flag  for  this  physical  line, 
function  IS_KILL_ON_EMPTY (  PHYS_LINE:  PHYSICAL_LINE  )  return  BOOLEAN; 

Determine  if  kill  when  queue  empty  flag  is  set  for  this  physical 
line. 


private 

type  LOGICAL_PORT  is 
record 

INTERCEPT:  array  (  PRECEDENCE,  MEDIAS  )  of  BOOLEAN; 
NAMESAKES:  LOGICAL_IDS; 

FORMAT:  FORMAT_TYPE  :=  ANY; 

PREFERRED_LMF:  LMF; 

LEVEL:  LEVEL_TYPE  :■  VALID_LEVEL(  2  ); 

ALT_PORTS,  PHYS_PORTS:  PHYS_PTR  :=  null; 
COMMUNITIES:  COMMUNITIES_SERVED  :=  R; 

XTS :  XTS  TYPE  :-  FALSE; 

MAX_RIS:  INTEGER  :»  MAX_NO_RIS_PER_DELIVERY (  0  ); 
CHARACTER  SET:  CHAR_SET_TYPE  :*  ANY; 

SPEC  TERM?  SPEC  TERM  TYPE  :«  ACCES; 
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AVAILABLE:  BOOLEAN  :>  FALSE; 

ALT_ROUTING:  BOOLEAN  :=  FALSE; 
end  record; 

LOG ICAL_T ABLE  :  array  (  LOGICAL_LINE ' FIRST  ..  LOGICAL_LINE' LAST  )  of 
LOGICALJPORT; 

type  PHYSICAL  PORT{  XMIT_MODE :  TRANSMISSION_MODE  :« 

SYNCH_BLK~BY_BLK  )  is 
record 

CHNL_MODE:  C HANN E L_MODE ; 

CURRENT_PRECEDENCE:  PRECEDENCE; 

START_TIME:  DATE  TIME; 

DIRECTION:  DIRECTION_TYPE  :=  BOTH; 

SECURITY:  SECURITY_CLASSIFICATION; 

SPEED:  LOOP_SPEED; 

KILL,  KILL_ON_EMPTY, 

AVAILABLE:  BOOLEAN  :*  FALSE; 

DESIGNATOR:  CHANNEL  DES; 
case  XMIT_MODE  is 

when  ASYNCH_NORMAL  I  ASYNCH_STEPPED  => 

STOP_BITS :  NO_STOP_BITS  :»  1; 

SOM_SEQ:  SOM_SEQ_TYPE  :»  FULL; 

ECSN ,  OCSN ,  RCSN:  CSN  :*  0; 
when  others  *> 
null; 
end  case; 
end  record; 

PHYSICAL_TABLE  :  array  (  PHYSICAL_LINE' FIRST  ..  PHYSICAL_LINE ' LAST  ) 
of  PHYSICAL_PORT; 

end  LINE_TBL_OPS; 
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3.4.2  Routing  Indicator  Operations 

The  table  in  the  following  section  is  used  by  the 
message  processing  software  to  determine  how  many 
copies  must  be  made  and  which  logical  channels  to 
route  them  over.  These  tables  are  initialized  by 
the  switch  operator  at  installation  time  and  may  be 
changed  from  the  operator  console  by  the  "Run  Switch" 
software. 
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with  GLOBAL_TYPES;  use  GLOBAL__TYPES ; 
package  RI_OPS  is 


—  NAME:  RI_OPS 

—  PURPOSE:  contains  data  definitions  and  procedures  required  to 

~  decode  routing  indicators  and  determine  the  required 

—  routing. 

—  PROGRAMMER:  Paul  Dobbs 

—  DATE:  May  17,  1982 


type  PORT_ENTRY ; 

type  ENTRY_PTR  is  access  PORT_ENTRY; 
type  PORT_ENTRY  is 
record 

ALT_ROUTING  :  BOOLEAN  :«  FALSE; 

PORT  :  LOGICAL_LINE; 

ALT_PORT  :  LOGICAL_LINE; 

NEXT  :  ENTRY_PTR; 
end  record; 

type  PORT_LIST  is  array (INTEGER  range  <>)  of  LOGICAL_LINE; 
subtype  RI_STRING  is  STRING (1 . .7 ) ; 
type  RI_LIST  ELEM; 

type  RI_PTR  Ts  access  RI_LIST_ELEM; 
type  RI_LIST_ELEM  is 
record 

RI:RI_STRING; 

NEXT_RI:RI_PTR; 
end  record; 

subtype  RELAY_STRING  is  STRING (1 . .4) ; 

procedure  READ_RI_TABLE (RI :RI_STRING;  PORTS :out  PORT_LIST; 
SUCCESS:out  BOOLEAN); 

—  READ  THE  RI  TABLE  AND  RETURN  THE  LOGICAL  LINE(S)  FOR  A 

—  SPECIFIC  RI 

—  SUCCESS  WILL  BE  SET  FALSE  IF  THE  RI  IS  NOT  FOUND 

type  CHECK  is  (NOT_FOUND, FOUND) ; 

function  CHECK_RI (RI :RI_STRING) return  CHECK; 

—  CHECK  FOR  THE  PRESENCE  OF  AN  RI  IN  THE  RI  TABLE 

procedure  ADD_RI(RI:RI  STRING; PORTS : ENTRY_PTR) ; 

—  ADDS  AN  RI  TO  THE  APPROPIATE  TABLE 

—  THE  PORT  ENTRY  LIST  FOR  ANY  RI  OTHER  THAN  A  COLLECTIVE  RI 

—  WILL  ONLY  HAVE  ONE  ENTRY 

procedure  DELETE_RI  (RI  :RI__STRING) ; 

—  REMOVES  AN  RI  FROM  THE~TABLES 
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procedure  CHANGE_RI (RI :RI_STRING; LINE: LOGICAL_LINE) ; 

—  SETS  THE  LOGICAL  LINE  FOR  A  NON_COLLECTIVE  RI 

procedure  CHANGE_COLLECTIVE_RI (RI :RI_STRING;OLD  LINE, 

NEW_LINE : LOGICAL_LINE) ; 

—  CHANGES  THE  PORT  ENTRY  FOR  OLD_LINE  TO  NEW  LINE 

—  IF  OLD_LINE  -  0,  ADDS  A  PORT  ENTRY 

—  IF  NEW_LINE  -  0,  DELETES  THE~PORT_ENTRY  FOR  THE  OLD__LINE 

procedure  CHANGE_ALT (RI :RI_STRING;  ALT_LINE : LOGICAL_LINE; 

START : BOOLEAN : -FALSE ) ; 

—  CHANGES  THE  ALT  ROUTING  FOR  A  NON_COLLECTIVE  RI 

—  IF  START  »  TRUE,  BEGINS  ALT  ROUTING 

procedure  CHANGE_COLLECTIVE_ALT (RI : RI_STRING ; LINE , 
ALT_LINE:LOGICAL_LINE;  START : BOOLEAN : -FALSE ) ; 

—  CHANGES  THE  ALT  ROUTING  FOR  ONE  PORT  ENTRY  OF  A  COLLECTIVE 

—  RI 

—  IF  START  -  TRUE,  BEGINS  ALT  ROUTING  FOR  THIS  PORT  ENTRY 

procedure  BEGIN_ALT (RI :RI_STRING) ; 

~  STARTS  ALT  ROUTING  FOR  A  NON-COLLECTIVE  RI 

procedure  BEGIN_COLLECTIVE_ALT (RI :RI  STRING; LINE :LOGICAL_LINE) ; 

—  STARTS  ALT  ROUTING  FOR  ONE  PORT  ENTRY  OF  A  COLLECTIVE  RI 

procedure  END_ALT (RI :RI_STRING) ; 

—  ENDS  ALT  ROUTING  FOR  A  NON-COLLECTIVE  RI 

procedure  END_COLLECTIVE_ALT (RI s RI_STRING ; LINE : LOGICAL_LINE) ; 

—  ENDS  ALT  ROUTING  FOR  A  PORT  ENTRY  OF  A  COLLECTIVE  RI 

procedure  LOAD_RI_TABLE ; 

—  LOADS  THE  RI  TABLES  FOR  START  UP 

procedure  S  AVE_R  I JT  ABLE; 

—  SAVES  THE  RIJTABLE  FOR  RESTARTS 

procedure  INIT_RI_TABLE; 

—  SETS  UP  AN  EMPTY  RIJTABLE 
end  RI_OPS; 


-135- 


Rationale  for  Hardware/Software  Partitioning 


.5 


Partitioning  of  the  system  functions  into  hardware  and 
software  was  done  with  the  primary  goal  of  maximizing  the 
system  efficiency  and  a  secondary  goal  of  minimizing  the 
amount  of  hardware.  Particular  implementations  were  not 
selected  but  rather  each  function  was  examined  for 
suitability  of  implementation  in  hardware  or  software. 

In  general,  most  of  the  functions,  or  operations  on  objects, 
were  partitioned  into  software  while  the  objects  themselves 
or  object  representations  were  partitioned  into  hardware. 

For  example,  translation  of  messages  was  selected  for 
software  implementation  while  the  messages  themselves  are 
represented  by  bit-patterns  in  some  form  of  memory 
( hardware) . 

The  exceptions  to  this  rule  are  the  actual  transmit  and 
receive  functions  for  both  synchronous  and  asynchronous 
formats.  These  functions  include  bit  stream  operations  and 
serial/parallel  conversions.  The  processes  are  well  defined, 
time  consuming,  and  mechanical  and  are  well  suited  to 
hardware  implementation.  In  addition,  there  are  many 
integrated  circuit  devices  available  which  implement  these 
functions  with  a  minimum  of  additional  hardware  and  software. 

Since  the  development  of  the  Message  Switch  proceeded 
directly  from  the  system  specification  and  requirements 
document,  it  evolved  into  a  functional  system  which  operated 
on  a  group  of  "objects".  As  such,  it  was  independent  of  any 
preconceived  hardware  system.  This  allowed  the  designers  to 
consider  various  hardware  approaches  for  implementation. 

Three  basic  hardware  configurations  were  examined:  1)  a 
single  large  central  processing  machine,  2)  a  distributed 
(several  smaller  machines)  and  3)  a  distributed  hierarchical 
(single  medium  sized  machine  with  several  smaller  distributed 
machines) . 

The  centralized  configuration  was  discarded  for  two  reasons. 
First,  the  designers  felt  that  it  was  unrealistic  to  expect 
Ada  to  be  able  to  handle  the  large  number  of  tasks  which 
would  be  required  (possible  one  thousand)  in  one  machine. 

And,  second,  it  is  doubtful  that  a  processor  is  available 
with  the  necessary  speed  and  power  to  handle  a  50  line 
switch,  with  the  possible  exception  of  a  Cray. 

The  distributed  configuration  was  considered  in  two 
variations,  a  vertical  and  a  horizontal.  For  example: 
putting  Input  in  one  processor,  Processing  in  another,  and 
Output  in  a  third,  as  opposed  to  say,  ten  inputs,  outputs, 
and  message  processing  in  each  of  five  processor  units. 

While  there  are  some  attractive  prospects  to  both  of  these 
variations,  the  disadvantages  outweighed  the  potential 
benefits.  The  disadvantages  included  excessive 
interprocessor  communication,  forced  sharing  of  tables  and 
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status  information  across  processor  boundaries,  and  the 
possibility  of  multiple  16K  bit  per  second  channels 
overloading  a  single  processor. 

The  designers  agreed  that  the  distributed  hierarchical  system 
is  the  best  configuration  for  a  message  switch  application. 
The  logical  result  of  the  hardware/software  partitioning,  as 
related  to  message  output  is  illustrated  in  Figure  3.5-1. 

The  design  consists  of  a  combination  of  the  two  variations  of 
the  distributed  approach,  and  as  such,  allows  the  designer  to 
take  advantage  of  the  strengths  of  both.  It  was  decided  that 
Input  and  Output  processing  would  be  maintained  on  a  lower 
level  compared  to  the  other  more  generalized  and  less  time 
critical  processes.  At  the  same  time  Input/Output  is  to  be 
spread  horizontally  over  several  processors  to  minimize  the 
chances  of  overloading  any  single  processor.  Combining  Input 
and  Output  in  the  same  processor  shortens  the  lines  of 
communication  between  the  two  processes  and  improves  the 
channel  Transmit  and  Receive  coordination.  An  additional 
advantage  is  availablity,  a  single  point  failure  would 
disable  no  more  than  eight  channels. 

Of  course  there  are  some  disadvantages  but  they  can  be 
minimized.  The  system  will  require  more  processors  and 
interprocessor  communication  will  be  needed,  causing  an 
increased  number  of  interconnections. 

Because  of  the  reduced  real  time  constraints  of  a  distributed 
system,  the  first  disadvantage  is  minimized  because  smaller 
and  less  expensive  processors  can  be  utilized.  There  is 
certainly  increased  overhead  because  of  interprocessor 
communication,  but  this  can  be  minimized  by  judicious 
partitioning  of  the  functions.  The  other  disadvantage  of 
interprocessor  communications,  which  is  the  additional 
hardware  interconnection,  can  be  minimized  by  using  a  medium 
speed  serial  data  bus  instead  of  a  parallel  bus. 

Because  it  was  not  known  how  much  support  would  be  provided 
by  the  Ada  run  time  package,  the  configuration  shown  in 
Figures  3.5-2  and  3.5-3  were  developed.  This  method  would 
not  depend  on  Ada  run  time  support,  but  unfortunately, 
becomes  quite  machine  dependent  and  reduces  transportability. 
Additional  logic  was  added  to  handle  serial  communication 
protocol  and  to  provide  low  level  support  functions  that  were 
no  longer  available  in  common  memory. 
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Figure  3.5-2  "OUTPUT  MESSAGE"  MAIN  PROCESSOR  SOFTWARE  DIAGRAM 


p 

to 

a: 

i 

o 

<! 

l. 

w 

>4 

o  > 

f 

M 

u 

a  b 
o  c 
r  c 
2 

m  * 

u  i 

t/5  b 

c/ 

gri'e 

Q  S  oc 
W  5  3 
O  5  u 
<gw 
>  u  w 


CHAR  BLOC! 


c 

U  nJ 
HOW 


Id  Z  S 
ZOO 
u  o 
o 


a  — 

S  2 

u  I  5  w 

>  X  O  J 

<  2  m  o 
J  r  z  z 
w  |  |  5 

z  ° 

,  5  U 


Figure  3.5-3  "OUTPUT  MESSAGE"  REMOTE  PROCESSOR  SOFTWARE  DIAGRAM 


Detailed  Hardware  Design 
General  Configuration 


Figure  M.1-1  illustrates  the  switch  system  design, 
consisting  of  a  generalized  computing  system  that  is 
optimized  for  real-time  communications  processing.  In  normal 
operation  incoming  messages  are  received  by  the  Line 
Termination  Units  (LTUs),  which  handle  the  line  level 
protocol  functions.  The  messages  are  assembled  into  segments 
for  transmission  to  the  active  main  processor.  At  the  main 
processor  the  segments  are  logged,  saved  on  reference 
storage,  translated  and  routed.  After  routing,  the  messages 
are  transferred  to  the  appropriate  LTU(s)  for  final 
validation  before  transmission  to  the  appropriate  stations. 

Start-up  of  the  system  takes  place  by  operator  action  and 
includes  loading  of  the  operational  programs  from  nonvolatile 
media.  Database  tables  may  be  loaded  from  nonvolatile  media 
by  operator  entry.  Operational  programs  for  the  LTUs  are 
down-loaded  via  the  serial  data  bus.  All  of  the  processors 
contain  a  "bootstrap"  and  diagnostic  program  in  Read  Only 
Memory. 

The  main  processor  may  be  any  general  purpose  machine  with 
the  necessary  speed  and  I/O  capability.  Some  special 
adaptation  will  be  required  to  facilitate  interprocessor 
monitoring  and  switchover.  Magnetic  tape  drives  are  included 
as  mass  storage  peripherals  for  sequential  storage 
applications  such  as  journals  and  intercepted  messages.  The 
disk  drives  are  intended  to  be  used  as  main  program  storage 
for  start-up,  mass  random  access  storage  for  intransit 
messages,  reference  storage  and  journals.  The  specification 
requires  that  intransit  storage  be  of  sufficient  size  to 
contain  2500  average  length  messages  for  a  50  line  switch. 
This  is  6,000,000  characters,  excluding  labels  and  linkage. 
Although  a  memory  of  this  size  is  possible  in  direct  access 
Read/Write  Memory  (such  as  semiconductor  RAM)  it  is  not  as 
cost  effective  as  using  large  capacity  disks.  Both  disk  and 
tape  peripherals  are  backed-up  with  a  redundant  unit  to 
prevent  single  failures  from  causing  a  system  outage. 

The  purpose  of  the  line  termination  units  (LTU)  are  to 
provide  time  critical  protocol  analysis  and  oversee  the  data 
send/receive  function  for  each  of  the  possible  fifty  channels 
of  the  message  switch.  Each  LTU  contains  a  general  purpose 
microcomputer  which  is  capable  of  being  downloaded  with 
channel  dependent  software.  There  also  exists  a  read-only 
memory  (ROM)  containing  the  bootstrap  program  for  start-up  of 
the  serial  bus  and  program  down-loading,  as  well  as 
diagnostics  and  fault  detection  firmware.  The  LTUs  contain 
the  necessary  circuitry  for  electrical  interfacing, 
controlling,  and  monitoring  crypto  and  modems  associated  with 
a  channel. 
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Figure  4.1-1  MESSAGE  SWITCH  HARDWARE  BLOCK  DIAGRAM 


4.2 


Serial  Data  Base 


A  redundant  data  bus  is  required  to  prevent  single  failures 
from  rendering  the  system  inoperative.  Physical  constraints 
associated  with  a  redundant  bus  virtually  eliminate  a 
parallel  bus  from  consideration.  Primarily,  the  large  number 
of  connections  required  to  propogate  a  parallel  bus  from 
circuit  board  to  circuit  board,  and  the  associated  cabling 
problems  are  prohibitive.  A  serial  bus  eliminates  these 
problems  by  requiring  that  only  two  cables  be  connected  to 
each  device  for  data  bus  access. 

The  ideal  solution  in  the  interconnect  area  as  well  as  the 
areas  of  throughput  and  error  is  to  use  the  MIL-STD-1 553B 
serial  bus.  This  selection  has  the  added  benefit  of  reducing 
risk  because  of  its  established  technology.  The  serial  bus 
is  used  to  transfer  message  segments,  control,  request,  and 
status  information  between  the  Main  processor  and  the  LTUs, 

.  as  well  as  updating  the  Status  Panel  Displays  and  down- 
.  loading  the  operational  programs  to  the  LTUs.  The  1553B 
Serial  Data  Bus  operates  at  a  1  MHz  bit  rate  and  is  capable 
of  transferring  480  bytes  of  data  plus  a  32  byte  label  in 
5.760  microseconds,  including  overhead  and  polling  time. 

This  is  a  bus  capacity  of  81,081  characters  (bytes  of  data) 
per  second.  The  specification  requires  a  50  line  switch  to 
be  capable  of  handling  a  maximum  of  9,000  characters  in  any 
one  second  period.  Therefore,  as  long  as  bus  overhead  stays 
below  8  times  the  maximum  data  handling  requirement  the 
serial  data  bus  will  be  equal  to  the  task.  Standard  serial 
bus  modules  are  available  commercially  and  are  designed  to 
use  DMA  capabilities  to  reduce  the  required  processor 
interactions . 

The  interprocessor  message  routing  is  determined  by  the 
physical  port  number.  LTU1  contains  ports  in  the  range  1-8, 
LTU2  range  9-16,  etc.  Although  it  is  not  necessary  that  all 
consecutive  ports  be  implemented  or  defined,  maximum  use  can 
be  made  of  the  hardware  by  defining  the  ports  in  groups  of 
four.  This  is  because  four  channels  are  supported  by  each 
interface  printed  circuit  board  (PCB). 

4.3  Line  Termination  Unit 


Each  LTU  shown  in  Figure  4.3-1  is  a  two  or  three  board  set 
consisting  of  a  CPU  Board  and  one  or  two  Channel  Boards. 

Each  channel  board  terminates  four  lines  (channels),  for  a 
maximum  of  eight  per  LTU.  This  flexibility  is  provided  so 
that  increased  processing  power  is  available  for  high  speed 
or  complex  channel  protocol.  On  the  other  hand,  a  larger 
quantity  of  low  speed  channels  in  a  grouping  can  also  be 
accommodated  by  adding  the  extra  channel  board.  The  main 
determining  factors  are  the  processor’s  speed  and  efficiency 
in  handling  the  channels. 
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Figure  4.3-1  LTU  BLOCK  DIAGRAM 


Each  LTU  is  equipped  with  its  own  dual  serial  bus  interface 
and  DMA  Controller  for  transferring  data  and  programs 
directly  to  and  from  an  on  board  dynamic  random  access  memory 
(RAM).  Each  channel  interface,  which  consists  of  serial 
data,  control,  clocks,  and  status  lines,  has  an  associated 
baud  rate  generator  and  interrupt  lines.  Other  functional 
blocks  are  self  explanatory  and  standard  for  a  microprocessor 
system. 

•  ^  Design  Features 

Several  features  of  this  design  are  worthy  of  mention. 
Although  it  is  expected  that  one  main  processor  is  sufficient 
for  operational  needs,  a  second  processor  is  included  for 
backup  and  monitoring  purposes.  The  serial  bus  terminals  of 
this  processor  are  initially  configured  as  a  remote  terminal 
but  are  capable  of  dynamic  reconfiguration  to  the  bus 
controller  mode  when  processor  switch-over  occurs.  Also  at 
the  time  of  processor  switch-over  the  failed  processor  is 
forced  to  relinquish  control  of  the  mass  storage  peripherals 
to  the  backup  processor. 

The  dual  serial  bus  is  redundant  with  automatic  error 
detection  capability.  Each  of  the  two  serial  busses  is 
capable  of  handling  the  full  specified  message  load  plus 
overhead . 

The  final  important  feature  is  the  treatment  of  operator 
terminals  and  local  equipment.  To  prevent  the  proliferation 
of  special  purpose  interfaces  this  equipment  is  interfaced 
through  Line  Termination  Units  in  the  same  manner  as  normal 
serial  communication  channels. 


5. 


Implementation  of  Selected  Function  (Output  Message) 


5. 1  Hardware  Implementation 

In  the  system  design  process  outlined  in  the  Ada  Integrated 
Methodology  the  hardware  design  and  implementation  are  a  part 
of  the  detailed  design  phase  of  system  development.  As  the 
Ada  Capability  Study  progressed,  the  output  component  was 
selected  as  the  module  to  be  designed  in  detail  and 
programmed  in  Ada.  For  this  reason,  more  attention  was  given 
to  the  design  of  the  LTUs  than  to  the  main  processor.  In  the 
design  process,  hardware  was  selected  which  has  performed 
well  in  similar  communications  applications.  It  is  not 
possible  at  this  time  to  know  for  sure  whether  Ada  compilers 
and  an  Ada  language  system  will  support  the  hardware 
selected . 

For  processing  power  and  flexibility,  an  8-bit  CPU  such  as  an 
INTEL  8088  is  recommended.  This  would  allow  for  upgrade  to  a 
16-bit  processor  such  as  the  8086,  if  additional  processing 
power  is  needed.  Such  an  upgrade  would  increase  the 
requirements  for  RAM,  ROM,  and  driver  ICs,  but  would  simplify 
the  serial  bus  interface  controller  because  the  bus  operates 
on  16-bit  words. 

The  following  sections  describe  the  two  printed  circuit 
boards  (PCB)  of  the  LTU  in  more  detail. 

5 . 2  LTU  Processor  PCB 

This  PCB,  illustrated  in  Figure  5.2-1,  comprises  the  elements 
that  are  common  to  all  of  the  controlled  serial  channels, 
such  as  the  serial  bus  interface,  CPU,  RAM,  and  ROM.  The 
only  item  which  is  unusual  in  the  context  of  a  general 
purpose  microcomputer  PCB  is  the  ID  Register.  This  ; egister 
is  a  set  of  "three-state"  bus  drivers  which  are  readable  by 
the  CPU.  The  inputs  to  the  drivers  will  be  connected, 
through  the  board  connector,  to  either  +5  volts  or  ground. 
Each  Processor  PCB  board  slot  will  be  programmed  (hand-wired 
on  the  back-plane)  with  a  unique  combination  of  logic  so  that 
each  processor  can  determine  its  own  address.  This  address 
will  be  the  one  that  the  Serial  Bus  Controller  will  use  when 
communicating  with  each  processor.  The  Processor  PCB  also 
contains  the  bus  driver  and  receivers  necessary  to 
communicate  with  one  or  two  channel  PCBs. 

Preliminary  estimates  of  parts  count  and  area  indicate  that 
the  ICs  required  will  fit  on  a  standard  77  square  inch  PCB, 
with  sufficient  margin  to  allow  for  the  processor  upgrade 
mentioned  earlier. 

5.3  LTU  Channel  PCB 

This  PCB,  as  illustrated  in  Figure  5.3-1 »  contains  the 
circuitry  necessary  to  interface  to  the  serial  channels  and 
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Figure  5.2-1  LTU  PROCESSOR  PCB  BLOCK  DIAGRAM 


\ 


the  associated  channel  equipment  (crypto  and/or  modems),  as 
well  as  baud  rate  generator,  and  the  processor  bus  interface 
circuits . 

Circuitry  for  four  serial  channels  is  provided  on  each  PCB. 
The  serial  channel  is  terminated  with  a  programmable  USART 
which  has  the  capability  to  transmit  and  receive  both 
synchronous  and  asynchronous  data.  A  Register  is  provided  to 
latch  control  outputs  for  crypto  and  modems,  as  well  as  a 
register  to  receive  status.  All  of  these  are  provided  with 
electrical  interfaces  to  perform  level  shifting  and  isolate 
the  external  lines  from  the  logic  circuits. 

The  Baud  Rate  Generator  is  programmable  and  can  provide 
different  clock  rates  for  any  of  up  to  four  asynchronous 
channels . 
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CHANNEL  1 

Figure  5.3-1  LTU  CHANNEL  PCB  BLOCK  DIAGRAM 


5.4  Software  Implementation 


The  software  implementation  for  this,  project  was  not  complete 
due  to  the  allowed  time  and  budget.  Since  the  message  output 
section  was  coded  in  Ada,  the  intended  switch  initialization 
and  operation  is  oriented  toward  that  portion  of  the  switch. 

5.4.1  Switch  Operation 

The  following  sequence,  although  not  implemented,  is  intended 
to  show  how  the  message  output  tasks  are  created  and  become 
ready  to  output  actual  messages  through  the  hardware.  A  key 
feature  of  this  deisgn  is  the  dynamic  allocation  and  deallocation 
of  output  tasks  in  order  to  support  database  changes  input 
by  the  operator  while  the  switch  is  in  operation. 

Power  Up  Link  protocol  and  bootstrap  are  stored  in  ROM  in 
both  processors,  so  the  bus  is  capable  of  running  on  power  up. 
However,  no  'output  message"  or  "send  sync/async"  tasks  are 
yet  defined  until  the  database  is  loaded. 

Switch  Initialization  Part  of  the  job  of  the  switch  initial¬ 
ization  routine  is  to  run  a  short  diagnostic  to  determine 
the  number  of  operational  remote  links.  This  process  would 
thus  determine  the  number  of  physical  ports  available  in  the 
system  and  print  a  copy  on  the  printer.  The  configuration 
is  determined  by  hard  wiring  of  the  connectors  into  which  the 
link  protocol  and  port  printed  circuit  boards  are  inserted. 

Data  Base  for  Output  Message  The  site  dependent  parameters 
(database)  are  entered  interactively  from  the  keyboard  of  a 
video  display  unit  (VDU)  or  from  a  pre-prepared  magnetic 
media  such  as  tape  or  disk  under  the  control  of  the  "run  switch" 
module. 

The  VDU  command  "define  physical  port"  will  prompt  the  user 
for  the  port  number  (or  range  of  numbers)  to  be  defined. 

In  addition,  information  such  as  channel  mode,  transmission 
rate  (baud),  security  level,  etc.  will  be  entered  as 
requested.  At  the  conclusion  of  each  port  definition  sequence, 
the  prompt:  "Is  this  information  correct  (Y  or  N)?"  will  appear. 
If  not  correct  the  sequence  will  be  repeated  until  the 
information  is  correct,  at  which  time  the  following  sequence 
will  occur: 

1.  Run  switch  will  lock  out  users  of  the  "line 

table",  update  the  necessary  line  table  information, 
and  unlock  the  table  in  the  main  processor.  Line 
table  information  needed  by  the  remote  processor 
will  be  transmitted  over  the  data  link  to  the 
remote  processor  corresponding  to  the  physical 
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port  number  for  entry  in  a  local  table. 

2.  Run  switch  uses  the  TASKS  package  to  create  a  new 
output  message  task  and  initialize  the  task  by 
issuing  the  physical  port  number.  The  TASKS  package 
consists  of  an  array  of  records  of  access  types 
(task  entry  point  for  various  output  message 
routines)  indexed  by  physical  port  number. 

3.  Run  switch  also  uses  the  TASKS  package  to  create  and 
initialize  the  Send  task  (Mode  I,  II  and  IV,  and  V) 
and  generate  and  receive  control  character  tasks, 

if  required,  (depends  on  channel  mode).  This 
process  is  communicated  over  the  interprocessor 
data  link  to  the  remote  processor  corresponding  to 
the  physical  port  being  changed. 


After  the  port  is  placed  into  active  service,  the  channel  is 
then  ready  to  output  message  data. 

An  example  of  the  calls  from  the  "Run  Switch"  to  the  "Tasks" 
package  in  order  to  initialize  physical  line  1  for  mode  V 
operation  is  as  follows: 


TABLE ( 1 ) . OUTPUT : -  new  OUTPUT_MESSAGE ; 

TABLE (1) .OUTPUT. INIT(l) ; 

TABLE ( 1 ) . SEND_V : *  new  SEND_MODE_V ; 
TABLE ( 1 ) . SEND_V . INIT ( 1 , UART  ADDRS ) ; 


--create  the  output 
--message  task. 

--tell  output  message 
--what  physical  line  he  is. 
--generate  mode  V  send  task, 
--tell  send  task  what  UART 
--to  use. 


TABLE (1 ) .GENCC:=  new  CONTROL_CHARACTER; --create  the  cntl  char  gen  tsl 
TABLE (1) .GENCC . INIT (1) ;  --tell  cntl  char  tsk  where  to  receive  chars 
TABLE (1 ) .RECVCC:=  new  CONTROL_CHARACTER ; 

TABLE (1) .RECVCC. INIT (1) ;  --  what  line  number  is  this 


5.4.2  Ada  "Output  Message"  Code 


This  code  is  contained  in  a  separate  document  due  to  its  length. 


